Fwd: Re: GNU M4 1.4.3 exit status

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary,

Is it worth a 1.4.4 release of m4?

- -------- Original Message --------
Subject: Re: GNU M4 1.4.3 exit status
Date: Mon, 10 Oct 2005 13:55:48 +0700 (ICT)
From: John Gatewood Ham <zappaman AT buraphalinux DOT org>
To: Eric Blake <ebb9 AT byu DOT net>
CC: address@hidden, address@hidden
References: <address@hidden>
<address@hidden>

Hello,

     Attached is the patch you requested.  'make check' still works.
Do you want me to add a test for this new behavior?  Do you want
the info file to contain information about EXIT STATUS like the
man page does?  I can add that if you wish.

JGH

On Sat, 8 Oct 2005, Eric Blake wrote:

> According to John Gatewood Ham on 10/8/2005 2:07 PM:
>>> GNU m4 people,
>>>
>>> When invoking m4 if you specify a file that does not exist
>>> the return code when exiting is still 0 but you have an error
>>> message.  The man page shows that you will exit with 0
>>> only if there are no errors.  I am using version 1.4.3
>>> compiled from source.
> 
> This is indeed a bug in 1.4.3, contrary to POSIX (which requires that if a
> program output diagnostic information to stderr, it fail with a nonzero
> exit status).
> 
>>>
>>> "EXIT STATUS
>>>        The following exit values shall be returned:
>>>
>>>         0     Successful completion.
>>>
>>>       >0     An error occurred"
> 
> A missing (or unreadable) input file counts as an error, and m4 should be
> patched to return 1 in that case.
> 
>>> The README file says send bugs to address@hidden,
>>> but the web page here http://www.seindal.dk/rene/gnu/feedback.htm
>>> says send them to address@hidden
>>>
>>> I sent it to both places to be sure.  I hope at least one
>>> of the addresses was the correct place to send this bug report.
> 
> bug-m4 is probably the best m4-specific list (and the one where I saw this
> mail), but <bug-gnu-utils AT gnu DOT org> is also well read.  The
> prep.ai.mit.edu domain is a holdover from historical past, although it may
> still forward properly.  In any case, you did the right thing in reporting
> it.  Just be aware that the official m4 maintainer is currently occupied
> with trying to get libtool 2.0 ready to release, so it may be a while
> before a patch to m4 is provided (unless you can volunteer to help
> contribute one).
> 

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDSmXu84KuGfSFAYARAoVTAKCST+8zxdRYAcKsM6MprXx9cMcVfQCfQ/Dq
zl28Y2QKZqcfDIUm+Raoy5A=
=mhnl
-----END PGP SIGNATURE-----

--- m4-1.4.3.orig/README        2004-08-21 17:29:00.000000000 +0700
+++ m4-1.4.3/README     2005-10-10 13:55:33.000000000 +0700
@@ -25,7 +25,7 @@
 feature which allows for changing the syntax of what is a "word" in
 `m4'.  This might go away, so don't count on it yet.
 
-Send bug reports to address@hidden'.  A bug report is
-an adequate description of the problem: your input, what you expected,
-what you got, and why this is wrong.  Diffs are welcome, but they only
-describe a solution, from which the problem might be uneasy to infer.
+Send bug reports to address@hidden'.  A bug report is an adequate 
+description of the problem: your input, what you expected, what you got, 
+and why this is wrong.  Diffs are welcome, but they only describe a 
+solution, from which the problem might be uneasy to infer.
--- m4-1.4.3.orig/src/m4.c      2005-02-10 03:58:38.000000000 +0700
+++ m4-1.4.3/src/m4.c   2005-10-10 13:52:11.000000000 +0700
@@ -263,6 +263,7 @@
   macro_definition *tail;
   macro_definition *new;
   int optchar;                 /* option character */
+  int retcode = EXIT_SUCCESS;
 
   macro_definition *defines;
   FILE *fp;
@@ -484,6 +485,14 @@
            if (fp == NULL)
              {
                error (0, errno, "%s", argv[optind]);
+               /*
+                * In order not to break existing applications that may
+                * depend on m4 continuing past non-existent files, I
+                * have decided to have m4 keep going as it always has
+                * past errors, but I make the final exit code be
+                * EXIT_FAILURE in this case.
+                */
+               retcode = EXIT_FAILURE;
                continue;
              }
            else
@@ -506,5 +515,5 @@
       undivert_all ();
     }
 
-  exit (EXIT_SUCCESS);
+  exit (retcode);
 }