Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!nosc!logicon.arpa!trantor.harris-atd.com!x102c!bbadger From: bbadger@x102c.harris-atd.com (Badger BA 64810) Newsgroups: comp.lang.c Subject: Re: entry at other than main (was: want to know) Message-ID: <2643@trantor.harris-atd.com> Date: 2 Sep 89 20:49:17 GMT References: <182@sunquest.UUCP> <14269@haddock.ima.isc.com> <1496@l.cc.purdue.edu> <1701@crdgw1.crd.ge.com> <2538@trantor.harris-atd.com> <10760@smoke.BRL.MIL> <2563@trantor.harris-atd.com> <10781@smoke.BRL.MIL> <2634@trantor.harris-atd.com> <14506@haddock.ima.isc.co Sender: news@trantor.harris-atd.com Reply-To: bbadger@x102c.harris-atd.com (Badger BA 64810) Organization: Harris GISD, Melbourne, FL Lines: 73 In article <14506@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >In article [...] (Badger BA 64810) writes: [...] >>If the burden of proof was on putting ``main()'' into a new language, instead ^^ Note well!! >>of taking it out of a language, how would you stand? > >That was addressed to Doug, but I'll answer it anyway. I'd put it in. > >But I see it the other way around; it's not so much a matter of "adding main() >to the language" as "removing PROGRAM from the language". It's simpler. In >FORTRAN, you've got three types of subprogram: functions, subroutines, and the >main program. In C, all three are combined into a single uniform entity. I >consider this a plus. > >Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint I know the burden of proof lies on the side proposing a change. That's why I said ``if''! It was a HYPOTHETICAL question. I want to address the ``main()'' issue from a clean slate to see if there is any reason to *put it in* the language. Again, this is hypothetical, so you can no longer say, ``That's the way it was always done before.'' Here's my list of reasons *for* using ``main()'': 1) It's very simple. Just have the linker call _start_up, and have crt0.o call main(). 2) ``main'' is mnemonic. It's easy to remember. 3) ``main'' is short, and easy to type. Better than ``startup_routine'' for instance. Reasons like, o ``FORTRAN and Pascal have a single main program.'' o ``All my C books say `main()' is the main procedure.'' o ``It's not portable. I won't be able to use the new code on REAL C.'' o ``All my REAL C code won't work with the new compiler.'' are non-responsive. I'm asking the hypothetical question: If you had a language like C in every way except that a routine called ``main()'' were treated exactly like any procedure with any other name, what reasons could you put forward for putting in the feature that every program must have a routine called ``main()'' which will be the first and only routine called after startup is finished? To help prevent off-the-track follow ups, let me state two things: 1) I'm not trying to actually change the way C works. I know this is a small detail in the language which can be trivially worked around. It doesn't really matter much either way. I'm sure there are lots of really important things which are better subjects for _real_ standards committees. I just wonder whether it deserves a secure place in the standard, because I can't see that the language would be any worse off without it. 2) I think that most current C compiler front-ends *already* work the way I want: ``main()'' _is_ an ordinary function. The fixation on main is only done in the linker or run-time support. In support of this, I note that ``A C Reference Manual'' by Harbison & Steele (1st ed., sorry) does not have an index entry for ``main'', neither does ``main'' show up in either syntax of C (app. B and app. C). program ::= { top-level-declaration }* top-level-declaration :== function-definition | declaration ----- - - - - - - - ---- Bernard A. Badger Jr. 407/984-6385 |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.