[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Re: GNU M4 1.4.3 exit status
From: |
Eric Blake |
Subject: |
Fwd: Re: GNU M4 1.4.3 exit status |
Date: |
Mon, 10 Oct 2005 07:00:30 -0600 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
-----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);
}
- Fwd: Re: GNU M4 1.4.3 exit status,
Eric Blake <=