delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/08/22/10:01:54

Message-ID: <3B837177.F0C4C3C2@acm.org>
From: Eric Sosman <esosman AT acm DOT org>
X-Mailer: Mozilla 4.72 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: exit( ) versus return 0; and abort
References: <3B88F7B3 AT MailAndNews DOT com> <200108211928 DOT PAA07064 AT envy DOT delorie DOT com>
Lines: 20
Date: Wed, 22 Aug 2001 13:41:54 GMT
NNTP-Posting-Host: 12.91.3.190
X-Complaints-To: abuse AT worldnet DOT att DOT net
X-Trace: bgtnsc04-news.ops.worldnet.att.net 998487714 12.91.3.190 (Wed, 22 Aug 2001 13:41:54 GMT)
NNTP-Posting-Date: Wed, 22 Aug 2001 13:41:54 GMT
Organization: AT&T Worldnet
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

DJ Delorie wrote:
> 
> A return from main is exactly the same as calling exit with the same
> value. [...]

    There is a slight difference: returning from main() discards any
`auto' variables it may have. This will be a problem if the end-of-run
cleanup activities try to refer to these no-longer-existing data
objects.

    How can it happen that post-program cleanup tries to use main()'s
`auto' variables?  One way is by registering functions with atexit()
and having them use pointers to variables which happen to be local
to main().  A slightly subtler problem is using setvbuf() to cause
some I/O stream to use a stack-resident buffer in main(); if this
stream is still open when main() returns there may be Hell to pay.

-- 
Eric Sosman
esosman AT acm DOT org

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019