Austin Group Defect Tracker

Aardvark Mark IV

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
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 [^]

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
child of 0000842Closed meaning of "enclosing loop" with break/continue unclear 

-  Notes
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.


    The application shall ensure that the value of n is a positive decimal integer.
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
2024-06-11 08:56 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker