🚀 go-pugleaf

   Date: Wed, 15 Apr 1992 08:37:59 -0400
   From: wollman@trantor.uvm.edu (Garrett Wollman)
   Newsgroups: gnu.gcc.bug
   Organization: University of Vermont, EMBA Computer Facility

   In article <9204150101.AA18863@life.ai.mit.edu> you write:
   >Why do all C programs call __main?  The change logs seem to say __main
   >is for C++ programs and shared libraries.

   __main is for programs linked with code requiring constructors and
   destructors, whether it be written in C, C++, or a mixture of the two.
   (For example, GNU libc or Per Bothner's stdio-over-iostreams
   implementation.)  It is the belief of the GCC developers that the user
   should not have to know what language her C library routines are
   written in.  I agree.  (That's also why GCC 2 always calls `collect'
   (or GNU ld) on systems that support it.)

Then whatever __main does really belongs in __start.

We have a similar problem in the mach libraries.  If you link with
cthreads, you have to call a cthread init routine before you can do
any system calls.  We solve this by having a function pointer that
starts out as zero and gets filled with the address of the cthread
init routine when cthreads is linked with the binary.  __start checks
this pointer and calls the init routine if non zero.  Non-intrusive.

   Besides, it's not /that/ difficult to create a null __main, is it?  Just
   take the version in libgcc2.c and delete the constructor/destructor setup.

That's not the point.  I'm already using "__main(){}" with no problem.
The point is that your compiler violates the least surprise principle
by giving me this bogus call to __main and not providing any way to
disable it.