Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mailrus!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Strange lint mumblings
Message-ID: <15185@mimsy.UUCP>
Date: 29 Dec 88 20:35:18 GMT
References: <416@marob.MASA.COM> <11467@dartvax.Dartmouth.EDU> <179@amsdsg.UUCP> <1700@valhalla.ee.rochester.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 38

This has been mentioned before but I had better do it again:

>In article <599@micropen> dave@micropen (David F. Carlson) writes:
>>... Rather, use return at the end of main().

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.

In what the dpANS calls a hosted environment---that is, in all the
interesting cases; in freestanding environments like a Unix kernel,
one generally cannot exit at all---return(expr) from main and
exit(expr) have identical effects.  The startup code that calls main
reads, essentially,

	exit(main(argc, argv, envp));

There are a few exceptions, notably some versions of SunOS.  These
read

	(void) main(argc, argv, envp);
	exit(0);

so that return(expr) from main is the same as exit(0).  There should
never be any difference between

	main() { return (0); }

and

	main() { exit(0); }

even on the buggiest implementations around.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris