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
0001229 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Error 2019-02-20 16:23 2024-06-11 09:08
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section <stdlib.h>
Page Number 359
Line Number 12240
Interp Status Approved
Final Accepted Text See Note: 0004407
Summary 0001229: EXIT_FAILURE should not be allowed to be all non-zero values
Description The value of EXIT_FAILURE in <stdlib.h> is allowed to be any non-zero
value. This is in conflict with the C standard, which requires that
exit(EXIT_FAILURE) returns "unsuccessful termination status" to the
host environment. Since the vast majority of applications use
either wait(), waitpid(), or $? in the shell to obtain this status,
and these truncate the value to the lower 8 bits, it follows that in
order to match the requirement in the C standard, POSIX needs to
specify that (EXIT_FAILURE & 255) is non-zero.

It could also be argued that (EXIT_FAILURE & 255) should not have a
value greater than 128 because when obtained via $? in the shell these
values are ambiguous, in that it is not possible to distinguish a call
to exit() with an argument > 128 from termination by a signal.

If we are going to disallow values > 128, it would also make sense to
disallow 126 and 127 since these are also ambiguous in certain
circumstances (the shell uses them as the exit status for commands
that it can't execute for various reasons).

Unless anyone knows of an implementation where (EXIT_FAILURE & 255)
is 128 we might as well disallow that as well, for simplicity, so that
only the range 1 to 125 is allowed.

Finally, calling exit() with a value greater than 255 is something that
only programs which are specifically designed to have their exit status
obtained by waitid() should do, so it seems odd to allow this to happen
for all "pure ISO C" programs that call exit(EXIT_FAILURE). To prevent
it, (EXIT_FAILURE & 255) should equal EXIT_FAILURE, leaving us with the
range 1 to 125 as the only allowed values for EXIT_FAILURE.

The proposed changes also include an editorial wording change to use
"shall".
Desired Action On page 359 line 12240 section <stdlib.h>, change:
EXIT_FAILURE
Unsuccessful termination for exit(); evaluates to a non-zero value
EXIT_SUCCESS
Successful termination for exit(); evaluates to 0.
to:
EXIT_FAILURE
Unsuccessful termination for exit(); [CX]the value shall be between 1 and 125 inclusive[/CX].
EXIT_SUCCESS
Successful termination for exit(); the value shall be 0.

On page 361 line 12340 section <stdlib.h>, change RATIONALE from:
None.
to:
The ISO C standard requires that <tt>exit(EXIT_FAILURE)</tt> returns ``unsuccessful termination status'' to the host environment. In a POSIX host environment this means that the lower 8 bits of EXIT_FAILURE must be non-zero. The standard developers decided to further restrict the allowed values for the following reasons:
  • Exit statuses of 126, 127, and greater than 128 are ambiguous in certain circumstances because they have special meanings in the shell (see [xref to XCU 2.8.2 Exit Status for Commands]).

  • Calling exit() with a value greater than 255 is something that only programs which are specifically designed to have their exit status obtained by waitid() should do (since it does not truncate the exit status to 8 bits). ``Pure ISO C'' programs that call <tt>exit(EXIT_FAILURE)</tt> do not meet this design criterion.
  • The value 128 is disallowed for simplicity, making the allowed values 1 to 125 inclusive rather than 1 to 125 inclusive and 128.

The requirement that the value of EXIT_SUCCESS is 0 is not shaded CX because this matches the requirement in the ISO C standard that <tt>exit(EXIT_SUCCESS)</tt> returns ``successful termination status'' to the host environment (when the host environment is a POSIX implementation).
Tags tc3-2008
Attached Files

- Relationships
related to 0001321Closed exit status for false should be 1-125 

-  Notes
(0004261)
eblake (manager)
2019-02-20 16:42

Historically, the Tandem/NSK system defined EXIT_FAILURE as -1 (which resulted in a status of 255 when 8-bit truncation occurs). However, this notably interferes with standardized behavior of xargs doing early termination when an 8-bit exit status of 255 is detected, enough so that gnulib intentionally declares Tandem/NSK as broken and redefines EXIT_FAILURE when building for that platform:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=d195802a [^]

So while it is a counterexample of a platform where EXIT_FAILURE is not between 1-125, it is also evidence for why this change is appropriate, although it may be yet another bullet point of rationale to add about the xargs behavior on exit(255)/exit(-1).
(0004269)
geoffclare (manager)
2019-02-27 11:53

Revised proposal:

On page 359 line 12240 section <stdlib.h>, change:
EXIT_FAILURE
Unsuccessful termination for exit(); evaluates to a non-zero value
EXIT_SUCCESS
Successful termination for exit(); evaluates to 0.
to:
EXIT_FAILURE
Unsuccessful termination for exit(); [CX]the value shall be between 1 and 125 inclusive[/CX].
EXIT_SUCCESS
Successful termination for exit(); the value shall be 0.

On page 361 line 12340 section <stdlib.h>, change RATIONALE from:
None.
to:
The ISO C standard requires that <tt>exit(EXIT_FAILURE)</tt> returns ``unsuccessful termination status'' to the host environment. In a POSIX host environment this means that the lower 8 bits of EXIT_FAILURE must have at least one bit set. The standard developers decided to further restrict the allowed values for the following reasons:
  • Exit statuses of 126, 127, and greater than 128 are ambiguous in certain circumstances because they have special meanings in the shell (see [xref to XCU 2.8.2 Exit Status for Commands]).

  • The xargs utility quits when a command execution exits with status 255 (see [xref to XCU xargs]).

  • Calling exit() with a value greater than 255 or less than 0 is something that only programs which are specifically designed to have their exit status obtained by waitid() should do (since it does not truncate the exit status to 8 bits). ``Pure ISO C'' programs that call <tt>exit(EXIT_FAILURE)</tt> do not meet this design criterion.

  • The value 128 is disallowed for simplicity, making the allowed values 1 to 125 inclusive rather than 1 to 125 inclusive and 128.
The requirement that the value of EXIT_SUCCESS is 0 is not shaded CX because this matches the requirement in the ISO C standard that <tt>exit(EXIT_SUCCESS)</tt> returns ``successful termination status'' to the host environment (when the host environment is a POSIX implementation).
(0004407)
nick (manager)
2019-06-06 15:20

Interpretation response
------------------------

The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
The ISO C standard requires that <tt>exit(EXIT_FAILURE)</tt> returns ``unsuccessful termination status'' to the host environment. In a POSIX host environment this means that the lower 8 bits of EXIT_FAILURE must have at least one bit set.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Make the changes in Note: 0004269
(0004607)
agadmin (administrator)
2019-10-07 15:17

Interpretation proposed: 7 October 2019
(0004651)
agadmin (administrator)
2019-11-11 12:20

Interpretation Approved: 11 Nov 2019

- Issue History
Date Modified Username Field Change
2019-02-20 16:23 geoffclare New Issue
2019-02-20 16:23 geoffclare Name => Geoff Clare
2019-02-20 16:23 geoffclare Organization => The Open Group
2019-02-20 16:23 geoffclare Section => <stdlib.h>
2019-02-20 16:23 geoffclare Page Number => 359
2019-02-20 16:23 geoffclare Line Number => 12240
2019-02-20 16:23 geoffclare Interp Status => ---
2019-02-20 16:42 eblake Note Added: 0004261
2019-02-27 11:53 geoffclare Note Added: 0004269
2019-06-06 15:20 nick Note Added: 0004407
2019-06-06 15:21 nick Interp Status --- => Pending
2019-06-06 15:21 nick Final Accepted Text => See Note: 0004269
2019-06-06 15:21 nick Status New => Interpretation Required
2019-06-06 15:21 nick Resolution Open => Accepted As Marked
2019-06-06 15:21 nick Tag Attached: tc3-2008
2019-06-06 15:22 nick Final Accepted Text See Note: 0004269 => See Note: 0004407
2019-10-07 15:17 agadmin Interp Status Pending => Proposed
2019-10-07 15:17 agadmin Note Added: 0004607
2019-11-11 12:20 agadmin Interp Status Proposed => Approved
2019-11-11 12:20 agadmin Note Added: 0004651
2019-12-04 11:49 geoffclare Status Interpretation Required => Applied
2020-01-29 16:40 geoffclare Relationship added related to 0001321
2024-06-11 09:08 agadmin Status Applied => Closed


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