Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!helios.ee.lbl.gov!nosc!logicon.arpa!trantor.harris-atd.com!x102c!bbadger From: bbadger@x102c.harris-atd.com (Badger BA 64810) Newsgroups: comp.lang.c Subject: Re: want to know Message-ID: <2561@trantor.harris-atd.com> Date: 18 Aug 89 20:51: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> <1989Aug16.203219.11825@cs.rochester.edu> <2549@trantor.harris-atd.com> <10770@smoke. Sender: news@trantor.harris-atd.com Reply-To: bbadger@x102c.harris-atd.com (Badger BA 64810) Organization: Harris GISD, Melbourne, FL Lines: 82 In article <10770@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <2549@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes: >>You use significant names for the files of your programs, why shouldn't you >>use significant names for the main routines? > >main() certainly is a descriptive name for the role of that pseudo-function >within a C application. The application within its invocation context has >yet another, hopefully descriptive, name ("grep"?) or icon (smiling frog?) >or whatever. Descriptive of what? I guess if you do something often enough it begins to seem natural. Why should there even _be_ a distinguished main program? Consider the compress/uncompress program, which changes its function based on the argv[0] string. To me, this is a clever work-around to a problem which has no _need_ to exist -- just let the program have multiple entry points. I know, you have to get the shell to invoke the program at a particular entry point, but this can be worked out. > >>There really wouldn't be any much change to C. Even now, main() isn't >>treated specially by the C compiler. > >Speak for yourself. The C compiler I use at home processes the main() >pseudo-function differently from other functions, and in general any >Standard-conforming implementation is going to have to give some degree >of special treatment to main(), since it doesn't follow quite the same >rules as normal C functions. OK, but the only thing special about main() that I found in the gcc compiler source code was to prevent main() from being inline-d. Exactly what does your C compiler _do_ differently for main? I don't see why a compiler would care that crt0.o happens to call main() eventually. What's so different about main()? That is, what rules are you inferring? > >The question has come up, can the main() function be invoked as a normal >C function (i.e. recursively by the application). I think it is not >guaranteed by the Standard; others think it is. This would be a good >thing for X3J11 to address in the "interpretations" phase. On my system (HCX-9 running HCX/UX 3.0), you can call main() from main(): --- begin cut here --- /* Can main () call main() ? * Print out arguments in reverse order. */ #includeint main(argc, argv ) int argc; char *argv[]; { if (argc > 0) { main(argc - 1, &argv[1]); if (argc > 1) putchar(' '); printf("%s",argv[0]); } return 0; } --- end cut here --- But why not allow this as a main program?: --- begin cut here --- /* * Print out arguments in reverse order. */ #include int reverse(argc, argv ) int argc; char *argv[]; { if (argc > 0) { reverse(argc - 1, &argv[1]); if (argc > 1) putchar(' '); printf("%s",argv[0]); } return 0; } --- end cut here --- Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!'' Secure Computer Products |``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.