Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!mimir!hugin!augean!idall From: idall@augean.OZ (Ian Dall) Newsgroups: comp.lang.c Subject: Re: want to know Message-ID: <566@augean.OZ> Date: 16 Aug 89 02:43:27 GMT References: <8487@bsu-cs.bsu.edu> <2980@solo9.cs.vu.nl> <182@sunquest.UUCP> <14269@haddock.ima.isc.com> <1496@l.cc.purdue.edu> Organization: Engineering Faculty, University of Adelaide, Australia Lines: 76 Reply-To: In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <14269@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: >> In article <664@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >> >[Name deleted on purpose] writes: >> >> I'm also a University's student in need of help. I always see that people >> >> define the function 'main' in C-programs. Why is that? What should it >> >> return? Can't I use another name? >> >> And the answer is somewhere between misleading and wrong. First of all, >> main() is special according to everything that resembles a standard: (K&R, >> H&S, D&M, pANS); this is a property of C, not of UNIX. Second, it is not >> special-cased by the linker in any UNIX implementation I know of. Rather, >> there is a pre-main routine that calls main() just like a normal function. > >No, the question is not a JOKE. It is a stupidity in UNIX which causes the >problem. I have used other systems in which the main program could have >any name whatever, and even in which the entry need not be to a main program, >while a main program is present. I have even used it. The UNIX kernal knows nothing about an entry point called main. Neither the compiler nor the assembler not the linker know anything special about "main". The 4.3 BSD ld arranges for execution to start at the beginning of the first file linked (normally crt0.o). The SysV linker normally arranges for execution to start at "start" or "_start" but be changed by options to ld. The only place where "main" appears explicitly is in the source for "crt0.o" which has the entry point "start" or "_start". If you have a burning desire to call your top level function something else I would suggest writing your own crt0.{c,s} and using a cpp parameter as the name of the function to call. You then recompile crt0 each time. >Those who remember the old Fortran will know that one normally had a PROGRAM >card, which was of the form > > PROGRAM NAME(.............) > >amd NAME was the name of the main entry point of the program. How many of those implimentations simply ignored the PROGRAM statement (except for the compiler error messages) and aranged some system standard entry point in the actual executable? > If you look at >the documentation of ld, it states that one can specify the original entry >point. This seems not to be implemented well in any version of UNIX with >which I am familiar, and frankly, I miss it. Works OK on my SysV system. Of course you have to understand that you are not changing the name of "main" but of "start" and crt0.o which you have left out might do important things on your system! >There is no even moderately fair reason why the user's program should start >at main (or _main if from C, or _MAIN_ if from Fortran). Most high level languages need some special code to be executed when the program first starts. Either the compiler needs to understand that the main program (by whatever name) is special and arrange the execution of that code to happen in the start of the main program, or the system has to arrange for a start up routine to be executed first which does the start up code and then calls the users main program. The way it is done in C (and it is a C standard) the compiler doesn't treats the main program like any other function which I think is kind of elegant. What do you actually want? Do you care what is in the actual executable symbol table? If not simply compile with cc -Dmymain=main -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others. idall@augean.oz