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.
 */
#include 
int 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.