 Relationships |
||||||
|
||||||
| Anonymous | Login | 2024-04-16 18:48 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 | 2019-10-28 10:02 | ||
| Reporter | stephane | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Applied | ||||||
| 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 | |||||||
|
|
|||||||
|
Relationships |
||||||
|
||||||
|
Notes |
|
|
(0003814) geoffclare (manager) 2017-08-10 16:02 |
On page 2386 line 76323 section 2.14 break, and page 2391 line 76496 section 2.14 continue, change: The value of n is a positive decimal integer. to: The application shall ensure that the value of n is a positive decimal integer. |
|
(0003815) eblake (manager) 2017-08-10 16:24 edited on: 2017-08-10 16:26 |
Regarding the issue of a 'break' or 'continue' inside a function definition, where the function is then run in a loop: this was already dealt with in bugid#842, where we added things such as line 76324: "If n is greater than the number of enclosing loops, the outermost enclosing loop shall be exited. If there is no enclosing loop, the behavior is unspecified." The unspecified nature is sufficient to cover warning messages, errors, or treating the function body as if it were inlined and breaking to the (now-enclosing) scope. Regarding 010 being decimal 10, the standard already states in XBD 12.1 item 6 (line 7239), as part of the utility syntax guidelines: "Unless otherwise specified, whenever an operand or option-argument is, or contains, a numeric value: - The number is interpreted as a decimal integer." and break/continue do not state otherwise. |
|
Issue History |
|||
| 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 |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
