Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!unmvax!indri!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: want to know Message-ID: <10760@smoke.BRL.MIL> Date: 17 Aug 89 14:59:17 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> <1701@crdgw1.crd.ge.com> <2538@trantor.harris-atd.com> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 26 In article <2538@trantor.harris-atd.com> bbadger@x102c.harris-atd.com writes: >Firstly, it is less informative to the user. Having a fixed entry like main >removes the possibility of a descriptive name being applied to a program. Program users do not see the name of the main() function at all. I don't think I've ever had a UNIX program called "main". >It also interferes with naming conventions for files and cross-reference tools >like ctags. Our local ctags has been modified to substitute ``Mfoo'' for >the symbol ``main()'' found in file ``foo.c''. This kind of game wouldn't >be required if C let you choose your main program name. It's not required anyway. There can be only one external function named main() among all the source files constituting a program. Besides, you shouldn't lay deficiencies in "ctags" at C's doorstep. >There are lots of UNIX programs written to simulate this by >switching on the value of argv[0] (the name the program was invoked by -- >see vi/ex, [ec]tags for examples), but this facility could be legitimized >by providing an entry point specification in exec(). Programs such as "vi" do NOT follow the model you suggest, and for exec to be able to do what you propose there would have to be substantial changes to the kernel and to the C run-time startoff module, adding overhead to essentially every UNIX process. I don't see that the putative benefits could possibly justify the cost.