Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!braner From: braner@batcomputer.tn.cornell.edu (Moshe Braner) Newsgroups: comp.lang.c Subject: Re: main() and exit() (was: Strange lint mumblings) Summary: does YOUR system always call exit() (rather than _exit())? Message-ID: <7082@batcomputer.tn.cornell.edu> Date: 29 Dec 88 16:58:59 GMT References: <416@marob.MASA.COM> <11467@dartvax.Dartmouth.EDU> <179@amsdsg.UUCP> <599@micropen> <1700@valhalla.ee.rochester.edu> <282@twwells.uucp> Reply-To: braner@tcgould.tn.cornell.edu (Moshe Braner) Distribution: na Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 26 On systems I have worked on, calling exit() links in most of the STDIO library modules, resulting in an executable program that is much bigger than it needs to be (in the case where you don't otherwise use STDIO). Calling _exit() instead does not link in STDIO. Does YOUR system's startoff code (that calls main()) call exit() or _exit()? Do you like the way it is? Other related observations/questions: exit() flushes stream I/O buffers. It also closes the files (releases the descriptors). Who closes non-STDIO files (the ones you opened with open() rather than fopen())? On my systems it seems that the OS closes the files (although I always use explicit calls to close() to be sure). Finally, what percentage of YOUR programs do NOT use STDIO (buffered streams, fopen/fread/putc/puts/printf...)? I try and avoid STDIO when programming small utilities for microcomputers, since they have small memories, slow disks, and no shared libraries. Also micro compilers come with direct screen/keyboard I/O functions. - Moshe Braner Cornell Theory Center, 265 Olin Hall, Cornell University, Ithaca, NY 14853 (607) 255-9401 (Work) (INTERNET) or (BITNET)