Anonymous | Login | 2024-10-09 03:01 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 | ||
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_FAILUREto:Unsuccessful termination for exit(); evaluates to a non-zero valueEXIT_SUCCESSSuccessful termination for exit(); evaluates to 0. EXIT_FAILUREUnsuccessful termination for exit(); [CX]the value shall be between 1 and 125 inclusive[/CX].EXIT_SUCCESSSuccessful 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: |
||||||
Tags | tc3-2008 | ||||||
Attached Files | |||||||
|
Relationships | ||||||
|
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_FAILUREto:Unsuccessful termination for exit(); evaluates to a non-zero valueEXIT_SUCCESSSuccessful termination for exit(); evaluates to 0. EXIT_FAILUREUnsuccessful termination for exit(); [CX]the value shall be between 1 and 125 inclusive[/CX].EXIT_SUCCESSSuccessful 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: |
(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 |