Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!lvc From: lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) Newsgroups: comp.lang.c Subject: Re: C Compiler bugs Summary: crt0.o is important Message-ID: <15298@tut.cis.ohio-state.edu> Date: 8 Jun 88 03:28:18 GMT References: <15085@tut.cis.ohio-state.edu> <4421@haddock.ISC.COM> <8036@brl-smoke.ARPA> Organization: Ohio State Computer & Info Science Lines: 28 In article <8036@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >A freestanding application has every right to define a main() function >having any valid interface. Agreed. >How does one get the compiler to compiler (sic) this code? As far as the compiler is concerned main is just another subroutine. A special one, but just another subroutine. My view of C compilers is that the name main is not special to the compiler, but when you want to take .o files and build an executable image there better be one main routine somewhere in those file for the startup routine to call. The compiler will automagically add a call to the startup routine to your program. I know, I know, so I've only used UNIX C compilers. >crt0.o has nothing to do with this. Why not? Freestanding applications, eg UNIX, have their own magical way of starting up. Imagine the chaos that would result if UNIX were compiled with /lib/crt0.o, yow! I think the crt0.o file (I spoke of previously) was recoded to always expect an int from main even if if it returned something else (our *crt.o files handle startup and termination). If the application really needs to return something else, then it isn't hosted and shouldn't use the "normal" crt0.o files.. I guess I don't see what point I am missing. -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)