Anonymous | Login | 2025-02-11 18:57 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001058 | [1003.1(2013)/Issue7+TC1] Shell and Utilities | Editorial | Clarification Requested | 2016-06-11 22:15 | 2024-06-11 08:56 | ||
Reporter | stephane | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Stephane Chazelas | ||||||
Organization | |||||||
User Reference | |||||||
Section | break utility | ||||||
Page Number | 2358 | ||||||
Line Number | 75119 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | Note: 0003814 | ||||||
Summary | 0001058: is it an error to call "break [n]" (or continue) when not in a loop? | ||||||
Description |
This is a follow-up on http://austingroupbugs.net/view.php?id=842#c3234 [^] The standard says that "break n" (resp "continue n"), where "n" is greater that the number of enclosing loops "m" shall be treated more or less as if "break m" (resp "continue m") was being called (the outermost loop is exited (resp. continued)). It does say it should be an error to call "break"/"continue" with an argument other than a strictly positive decimal integer (would "break 0" be a "syntax error" and cause the shell to exit as "break"/"continue" are special built-in? It is in a few shells but the fact that the "RETURN STATUS" section mentions an exit code >0 in that case suggests the shell shall not exit). But it doesn't really make it clear what should happen if "break" or "continue" are being called not from within a "loop". With bug 842 that extends to contexts where enclosing loops may not be considered as such like in: f() { break; } for i in 1 2; do echo "$i"; f; done In practice, all POSIX-like shells I tried but AT&T ksh output an error message in that case. Not all return with a non-zero exit status or exit the shell though. Also when called from within a loop but with n > m, some shells (the pdksh-derived ones) do output a warning message which sounds like a good idea as they help identify coding mistakes, but doesn't look like is allowed by the spec. |
||||||
Desired Action |
Make it clear that it's unspecified whether it's an error or not (and if that may cause the shell to exit or not) to call "break"/"continue" not inside a loop (in the current function/dotted-script context). Make it unspecified whether "break <anything-but-a-strictly-positive-integer>" shall be considered as a syntax error or not (with the "exiting the shell" consequence when not called via "command"). Maybe something like "a strictly conforming application shall make sure that "break n"/"continue n" shall only be called if n is <= the number of enclosing loops" and to allow the pdksh behaviour: "implementations may issue a warning if n is greater". Also, it may already be covered somewhere else, but if not, make it clear that 010 is the decimal number 10, and not an error because it's octal and not decimal. |
||||||
Tags | tc3-2008 | ||||||
Attached Files | |||||||
|
![]() |
||||||
|
![]() |
|||
Date Modified | Username | Field | Change |
2016-06-11 22:15 | stephane | New Issue | |
2016-06-11 22:15 | stephane | Name | => Stephane Chazelas |
2016-06-11 22:15 | stephane | Section | => break utility |
2016-06-11 22:15 | stephane | Page Number | => 2358 |
2016-06-11 22:15 | stephane | Line Number | => 75119 |
2017-08-10 16:00 | Don Cragun | Relationship added | child of 0000842 |
2017-08-10 16:02 | geoffclare | Note Added: 0003814 | |
2017-08-10 16:03 | geoffclare | Interp Status | => --- |
2017-08-10 16:03 | geoffclare | Final Accepted Text | => Note: 0003814 |
2017-08-10 16:03 | geoffclare | Status | New => Resolved |
2017-08-10 16:03 | geoffclare | Resolution | Open => Accepted As Marked |
2017-08-10 16:03 | geoffclare | Tag Attached: tc3-2008 | |
2017-08-10 16:24 | eblake | Note Added: 0003815 | |
2017-08-10 16:25 | eblake | Note Edited: 0003815 | |
2017-08-10 16:26 | eblake | Note Edited: 0003815 | |
2019-10-28 10:02 | geoffclare | Status | Resolved => Applied |
2024-06-11 08:56 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |