Re: FATAL_EXIT_CODE - why 33?

[Michael Meissner <meissner at cygnus dot com>]

(by the way Zack -- please don't use gcc-patches for asking questions, that's
what the gcc mailing list is for)

On Fri, Mar 02, 2001 at 05:16:20PM +1100, Fergus Henderson wrote:
> On 01-Mar-2001, Zack Weinberg <zackw@stanford.edu> wrote:
> > Does anyone know why the usual definition of FATAL_EXIT_CODE by
> > xm-foo.h is 33?
> 
> I don't know, but I'm guessing probably for hysterical raisins.
> 
> There's an obsolete comment in toplev.c which says
> 
>  | /* Entry point of cc1/c++.  Decode command args, then call compile_file.
>  |    Exit code is 35 if can't open files, 34 if fatal error,
>  |    33 if had nonfatal errors, else success.  */
>  | 
>  | extern int main PARAMS ((int, char **));
> 
> That comment is wrong, since if anything goes wrong it always returns
> FATAL_EXIT_CODE, never 34 or 35.

As I said in my previous message, it used to return 34 and 35 before 1995.

> In my still unreviewed patch (hint, hint ;-) to move main() from toplev.c to
> a new file <http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00577.html>,
> I replaced that comment with one that matched what the code actually does:
> 
>  |    Exit code is FATAL_EXIT_CODE if can't open files or if there were
>  |    any errors, or SUCCESS_EXIT_CODE if compilation succeeded.
> 
> My guess is that when FATAL_EXIT_CODE was introduced and the code in topleve.c
> was changed to use FATAL_EXIT_CODE rather than hard-coding 33/34/35,
> FATAL_EXIT_CODE may have been defined as 33 for backwards compatibility.

Yep.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482