Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Strange lint mumblings
Message-ID: <282@twwells.uucp>
Date: 29 Dec 88 06:21:47 GMT
References: <416@marob.MASA.COM> <11467@dartvax.Dartmouth.EDU> <179@amsdsg.UUCP> <599@micropen> <1700@valhalla.ee.rochester.edu>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 46
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

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. I have personally not had this problem with return/exit in lint, so I
: shall continue to use exit (maybe I should use egress as PT Barnum once
: did :-)

Returning from main does all these things on every system I know of.
In other words,

main()
{
	...
	return (0);
}

and

main()
{
	...
	exit(0);
}

are pretty much equivalent. Generally, main is called from another
routine which, besides setting up the C run-time environment, does
something like:

crt0(argc, argv)
{
	exit(main(argc, argv));
}

The only exception that I know of to this are systems, like certain
versions of SunOS, that behave more like:

crt0(argc, argv)
{
	main(argc, argv);
	exit(0);
}

---
Bill
{uunet|novavax}!proxftl!twwells!bill