View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000964 | 1003.1(2013)/Issue7+TC1 | Shell and Utilities | public | 2015-06-24 14:17 | 2019-06-10 08:54 |
| Reporter | geoffclare | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | m4 | ||||
| Page Number | 2902 | ||||
| Line Number | 95774 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0000964:0002823. | ||||
| Summary | 0000964: should m4 treat mkstemp failure as an error? | ||||
| Description | When mkstemp cannot create a file, it's not clear whether m4 should treat this as an error as regards its exit status and any message written to stderr. GNU m4 doesn't treat it as an error according to its exit status, but it does write a message to stderr, which the standard does not allow for exit 0. Applications can use errprint to write their own error message if mkstemp's defining text is empty, but they can't tell the reason the file could not be created (which GNU m4 includes in the message it writes). Therefore it would be better for the standard to require that m4 writes a message, but in this case the final exit status should be non-zero. | ||||
| Desired Action | On Page: 2902 Line: 95774 Section: m4 In the EXTENDED DESCRIPTION section, for mkstemp change from: If a file could not be created, the defining text of the macro shall be the empty string. to: If a file could not be created, m4 shall write a diagnostic message to standard error and shall continue processing input but its final exit status shall be non-zero; the defining text of the macro shall be the empty string. | ||||
| Tags | tc2-2008 | ||||
|
|
I don't mind changing GNU m4 to force a non-zero exit status upon mkstemp returning an empty string. |
|
|
This note is superseded by 0000964:0002823. 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 standard does not clearly specify what should happen if a file cannot be created in this case. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes suggested in the Desired Action. |
|
|
Other cases exist where GNU m4 writes to stderr, but doesn't currently force a non-zero exit. For example, the standard says "It shall be an error to specify the second [argument of expr] containing any non-numeric characters", but: $ echo 'eval(1,a)' | POSIXLY_CORRECT=1 m4; echo $? m4:stdin:1: non-numeric argument to builtin `eval' 0 Should we relax the standard to allow warnings, or go the opposite direction and require that any error encountered (not just mkstemp errors) affects final exit status? And what happens if we require non-zero status but continuation of script parsing, and later in the script contains m4exit(0)? Does the user's request for 0 status override or get masked by the earlier error? |
|
|
GNU m4 has both warnings (such as bad arguments to eval) and latched errors (such as failure to open a file); latched errors indeed override attempts to m4exit(0): $ printf 'bye\nm4exit(0)' | POSIXLY_CORRECT=1 m4 nosuch -; echo $? m4: cannot open `nosuch': No such file or directory bye 1 |
|
|
Interpretation Proposed: 17 July 2015 |
|
|
(Response to 0000964:0002761 and 0000964:0002763) I believe the standard already requires a non-zero exit status for eval(1,a), courtesy of the "it shall be an error" wording, and I think non-zero exit is the right thing to do because this is an error in the application. The reason for wording the mkstemp() case differently in the desired action is because just saying "it shall be an error" would allow m4 to exit at that point, whereas the intention is that it should continue processing (otherwise there would no point in requiring the defining text to be the empty string). Regarding m4exit(0), on Solaris this overrides the non-zero exit status from an ENOENT error: $ printf 'bye\nm4exit(0)' | m4 nosuch -; echo $? m4: cannot open nosuch: No such file or directory bye 0 So it looks like we will have to either leave the standard silent on this or make it explicitly unspecified (for TC2 - we could tighten the requirement in Issue 8 if desired). |
|
|
Due to issues raised during the earlier interpretation review process, this new interpretation is being proposed and the timer will be restarted: 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 standard does not clearly specify what should happen if a file cannot be created in this case. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Change the description of m4exit from: Exit from the m4 utility. If the first argument is specified, it is the exit code. The default is zero. It shall be an error to specify an argument containing any nonnumeric characters. to: Exit from the m4 utility. If the first argument is specified, it shall be the exit code. If no argument is specified, the exit code shall be zero. It shall be an error to specify an argument containing any nonnumeric characters. If the first argument is zero or no argument is specified, and an error has previously occurred (for example, a file operand that could not be opened), it is unspecified whether the exit status is zero or non-zero. In the EXTENDED DESCRIPTION section, for mkstemp change from: If a file could not be created, the defining text of the macro shall be the empty string. to: If a file could not be created, m4 shall write a diagnostic message to standard error and shall continue processing input but its final exit status shall be non-zero; the defining text of the macro shall be the empty string. |
|
|
Revised Interpretation proposed: 11 Sep 2015 |
|
|
Interpretation approved: 6 November 2015 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-24 14:17 | geoffclare | New Issue | |
| 2015-06-24 14:17 | geoffclare | Name | => Geoff Clare |
| 2015-06-24 14:17 | geoffclare | Organization | => The Open Group |
| 2015-06-24 14:17 | geoffclare | Section | => m4 |
| 2015-06-24 14:17 | geoffclare | Page Number | => 2902 |
| 2015-06-24 14:17 | geoffclare | Line Number | => 95774 |
| 2015-06-24 14:17 | geoffclare | Interp Status | => --- |
| 2015-07-16 15:22 | eblake | Note Added: 0002758 | |
| 2015-07-16 15:27 | Don Cragun | Note Added: 0002759 | |
| 2015-07-16 15:27 | Don Cragun | Status | New => Interpretation Required |
| 2015-07-16 15:27 | Don Cragun | Resolution | Open => Accepted |
| 2015-07-16 15:27 | Don Cragun | Desired Action Updated | |
| 2015-07-16 15:28 | Don Cragun | Interp Status | --- => Pending |
| 2015-07-16 15:28 | Don Cragun | Final Accepted Text | => See 0000964:0002759. |
| 2015-07-16 15:28 | Don Cragun | Tag Attached: tc2-2008 | |
| 2015-07-16 15:39 | eblake | Note Added: 0002761 | |
| 2015-07-16 15:58 | eblake | Note Added: 0002763 | |
| 2015-07-16 19:55 | eblake | Relationship added | related to 0000970 |
| 2015-07-17 07:59 | ajosey | Interp Status | Pending => Proposed |
| 2015-07-17 07:59 | ajosey | Note Added: 0002768 | |
| 2015-07-17 09:37 | geoffclare | Note Added: 0002770 | |
| 2015-09-10 15:25 | Don Cragun | Note Added: 0002823 | |
| 2015-09-10 15:28 | Don Cragun | Note Edited: 0002823 | |
| 2015-09-10 15:29 | Don Cragun | Final Accepted Text | See 0000964:0002759. => See 0000964:0002823. |
| 2015-09-10 15:30 | Don Cragun | Interp Status | Proposed => Pending |
| 2015-09-10 15:31 | Don Cragun | Resolution | Accepted => Accepted As Marked |
| 2015-09-10 15:33 | Don Cragun | Note Edited: 0002759 | |
| 2015-09-11 06:41 | ajosey | Interp Status | Pending => Proposed |
| 2015-09-11 06:41 | ajosey | Note Added: 0002825 | |
| 2015-09-11 13:54 | geoffclare | Relationship added | related to 0000984 |
| 2015-11-06 10:33 | ajosey | Interp Status | Proposed => Approved |
| 2015-11-06 10:33 | ajosey | Note Added: 0002888 | |
| 2019-06-10 08:54 | agadmin | Status | Interpretation Required => Closed |
