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
0000984 [1003.1(2013)/Issue7+TC1] Shell and Utilities Objection Enhancement Request 2015-09-11 13:53 2020-04-08 15:37
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
Name Geoff Clare
Organization The Open Group
User Reference
Section m4
Page Number 2902
Line Number 95756-95758
Interp Status ---
Final Accepted Text Implement the desired action.
Summary 0000984: m4exit(0) after an error should result in non-zero exit status
Description Implementations differ in the exit status of m4 when m4exit(0) is
called after an error has occurred. For TC2 this is being made
explicitly unspecified via 0000964. However, for Issue 8 a
non-zero exit should be specified because exiting with zero status
hides the fact that an error occurred from shell scripts that check
the exit status of m4.
Desired Action On page 2902 line 95756-95758, after applying bug 964 change:

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.

to:

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), the exit status shall be non-zero.

On page 2905 line 95905 add a new paragraph to the RATIONALE section:

Earlier versions of this standard allowed the exit status to be
either zero or non-zero when <tt>m4exit(0)</tt> is called after an error has
occurred. Exiting with zero status is now disallowed as this hides
the fact that an error occurred from shell scripts that check the
exit status of m4.
Tags issue8
Attached Files

- Relationships
related to 0000964Closed should m4 treat mkstemp failure as an error? 

-  Notes
(0002826)
shware_systems (reporter)
2015-09-11 15:16

Please change to:
...the exit status shall be the non-zero code representing the error detected. It is implementation-defined whether a diagnostic is written to stderr that an override of the error return was attempted, as an aid to debugging.

Leaving it as simply non-zero means returning 1 in all cases would be conforming, but the code for "file can't be opened" might be 27. While as is only pass/fail logic in scripts is portable, for implementation-specific scripts recovery code will need the number assigned by the implementation, imo.
(0003278)
joerg (reporter)
2016-06-30 16:35

Which m4 implementation behaves the way requested by the desired actions for this bug?

Solaris m4 does not seem to behave this way and gm4 also does not behave this way.
(0003280)
geoffclare (manager)
2016-07-01 08:39

GNU m4 behaves that way. See Note: 0002763
(0003286)
joerg (reporter)
2016-07-05 09:48

printf 'bye\nm4exit(0)' | POSIXLY_CORRECT=1 gm4 nosuch -; echo $?
gm4: nosuch: No such file or directory
bye
0

I cannot repeat your claim.

So my conclusion is that there is no implementation that behaves like the
proposal and the proposal is in conflict with other UNIX behavior.

The shell e.g. exits with the last exit code if you omit the "exit" parameter.

false
exit

does e.g. cause the shell to exit with a non-zero exit code while

false
exit 0

causes the shell to exit with a zero exit code.

An non-zero exit code from m4exit(0) is highly confusing and cannot
be accepted.
(0003287)
geoffclare (manager)
2016-07-05 10:07

I can reproduce Eric's result on a Debian "Jessie" system:

$ m4 --version | head -n 1
m4 (GNU M4) 1.4.17
$ printf 'bye\nm4exit(0)' | POSIXLY_CORRECT=1 m4 nosuch -; echo $?
m4: cannot open `nosuch': No such file or directory
bye
1

Presumably Eric used an up-to-date Red Hat system.

Your "gm4" whatever that is, does not behave the same as current versions of GNU m4.

Your comparison of m4 with the shell is not relevant because the situation being addressed here for m4 cannot happen in the shell (because the shell does not accept multiple command_file operands).
(0003288)
nick (manager)
2016-07-07 02:17
edited on: 2016-07-07 02:18

I agree Geoff; in addition, git blame on GNU m4 tells me the Eric knows the answer better than anyone (he was the committer for this: 2006-07-27 Eric Blake <ebb9@byu.net>)!

(0003289)
joerg (reporter)
2016-07-07 11:59
edited on: 2016-07-07 11:59

I did check GNU m4 1.4.2

and if a sub-minor release introduces such an incompatible change, this
does not look like a good idea to follow.

Let me again give the reason, why the proposal is not acceptable:

- it prevents controllable behavior.

- calling m4exit (without a parameter) to return with the error state
  is sufficient

- permitting to call m4exit(0) or whatever value keeps the control in
  the hands of the programmer.

(0003290)
geoffclare (manager)
2016-07-07 14:50

Having control in the circumstance in question is of no use to the programmer because the programmer has no way of finding out whether a file-not-found error has previously occurred in order to decide whether calling m4exit(0) would be appropriate. Therefore your proposed alternative would simply result in m4exit(0) being something that should never be called. Existing GNU m4 programs that call it would need to be changed to call m4exit() with no parameter.

You seem to be the only person to whom "the proposal is not acceptable". Everyone else on the 30th June conference call was happy to accept it.

- Issue History
Date Modified Username Field Change
2015-09-11 13:53 geoffclare New Issue
2015-09-11 13:53 geoffclare Name => Geoff Clare
2015-09-11 13:53 geoffclare Organization => The Open Group
2015-09-11 13:53 geoffclare Section => m4
2015-09-11 13:53 geoffclare Page Number => 2902
2015-09-11 13:53 geoffclare Line Number => 95756-95758
2015-09-11 13:53 geoffclare Interp Status => ---
2015-09-11 13:54 geoffclare Relationship added related to 0000964
2015-09-11 15:16 shware_systems Note Added: 0002826
2016-06-30 16:23 Don Cragun Final Accepted Text => Implement the desired action.
2016-06-30 16:23 Don Cragun Status New => Resolved
2016-06-30 16:23 Don Cragun Resolution Open => Accepted
2016-06-30 16:23 Don Cragun Tag Attached: issue8
2016-06-30 16:35 joerg Note Added: 0003278
2016-07-01 08:39 geoffclare Note Added: 0003280
2016-07-05 09:48 joerg Note Added: 0003286
2016-07-05 10:07 geoffclare Note Added: 0003287
2016-07-07 02:17 nick Note Added: 0003288
2016-07-07 02:18 nick Note Edited: 0003288
2016-07-07 11:59 joerg Note Added: 0003289
2016-07-07 11:59 joerg Note Edited: 0003289
2016-07-07 14:50 geoffclare Note Added: 0003290
2020-04-08 15:37 geoffclare Status Resolved => Applied


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