main() and exit() (was: Strange lint mumblings)
Doug Gwyn
gwyn at smoke.BRL.MIL
Mon Jan 2 12:36:00 AEST 1989
In article <7082 at batcomputer.tn.cornell.edu> braner at 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.
More information about the Comp.lang.c
mailing list