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: main() and exit() (was: Strange lint mumblings) Message-ID: <9253@smoke.BRL.MIL> Date: 2 Jan 89 02:36:00 GMT References: <416@marob.MASA.COM> <11467@dartvax.Dartmouth.EDU> <179@amsdsg.UUCP> <599@micropen> <1700@valhalla.ee.rochester.edu> <282@twwells.uucp> <7082@batcomputer.tn.cornell.edu> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Distribution: na Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 45 In article <7082@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: >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). This didn't happen on UNIX systems before "ranlib" invaded, because the C library provided two modules containing the same entry point, one linked in when any part of STDIO was linked and the other module otherwise. The same trick was also used to leave out the floating- point formatted I/O conversion support when no module being linked contained any floating-point code. (Remember, the PDP-11 had a 64K byte process size limit.) >Calling _exit() instead does not link in STDIO. Does >YOUR system's startoff code (that calls main()) call exit() or _exit()? It damn well better call exit(), which on systems conforming to the C standard will flush STDIO buffers and invoke any functions registered via atexit(), and which on POSIX-conforming systems will then invoke the _exit() system call interface. >Who closes non-STDIO files (the ones you opened with open() rather >than fopen())? On UNIX, which is what all those systems providing open() are mimicking, a process's open file descriptions are closed when the process terminates. (What else would you expect?) An accurate emulation should do the same, or at the very least close everything in sight on exit(). >Finally, what percentage of YOUR programs do NOT use STDIO (buffered >streams, fopen/fread/putc/puts/printf...)? Not more than 10%. >I try and avoid STDIO when programming small utilities for >microcomputers, since they have small memories, slow disks, and no >shared libraries. There seems to be an assumption that a STDIO implementation has to be slow and bulky. That is WRONG. >Also micro compilers come with direct screen/keyboard I/O functions. Which of course don't constitute a portable interface.