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
0000964 [1003.1(2013)/Issue7+TC1] Shell and Utilities Objection Clarification Requested 2015-06-24 14:17 2019-06-10 08:54
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 m4
Page Number 2902
Line Number 95774
Interp Status Approved
Final Accepted Text See Note: 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
Attached Files

- Relationships
related to 0000970Closedajosey mkstemp() description permits mode 0640 or 0620, should only permit 0600 
related to 0000984Applied m4exit(0) after an error should result in non-zero exit status 

-  Notes
(0002758)
eblake (manager)
2015-07-16 15:22

I don't mind changing GNU m4 to force a non-zero exit status upon mkstemp returning an empty string.
(0002759)
Don Cragun (manager)
2015-07-16 15:27
edited on: 2015-09-10 15:33

This note is superseded by Note: 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.

(0002761)
eblake (manager)
2015-07-16 15:39

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?
(0002763)
eblake (manager)
2015-07-16 15:58

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
(0002768)
ajosey (manager)
2015-07-17 07:59

Interpretation Proposed: 17 July 2015
(0002770)
geoffclare (manager)
2015-07-17 09:37

(Response to Note: 0002761 and Note: 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).
(0002823)
Don Cragun (manager)
2015-09-10 15:25
edited on: 2015-09-10 15:28

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.


(0002825)
ajosey (manager)
2015-09-11 06:41

Revised Interpretation proposed: 11 Sep 2015
(0002888)
ajosey (manager)
2015-11-06 10:33

Interpretation approved: 6 November 2015

- Issue History
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 Note: 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 Note: 0002759. => See Note: 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


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