Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!ukma!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Strange lint mumblings
Message-ID: <9251@smoke.BRL.MIL>
Date: 2 Jan 89 02:05:37 GMT
References: <416@marob.MASA.COM> <11467@dartvax.Dartmouth.EDU> <179@amsdsg.UUCP> <599@micropen> <1700@valhalla.ee.rochester.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <1700@valhalla.ee.rochester.edu> badri@valhalla.ee.rochester.edu (Badri Lokanathan) writes:
>Alas, some of us (at least I) have gotten used to the easy clean up facility
>that exit() provides. That is, flushing all I/O buffers and closing
>them. return(status) works cleanly if the programmer takes care of
>this.

Oh, come on.  Return from main() is ALSO supposed to do this; it's
practically like a coroutine jump to exit() with the return value
being passed to exit as its argument.

The real problem comes when you try to return a non-zero termination
status via "return N;" from main() on a system like some releases of
SunOS where the run-time start-off code has been "hot wired" to force
an exit(0) whenever main returns.  That was a mistake that needs to
be fixed, but small consolation if it bites you.