From 4824446481748004229
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1149ec,c16a8bbbb9f41338
X-Google-Attributes: gid1149ec,public
X-Google-Thread: f78e5,c16a8bbbb9f41338
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-09-01 18:09:26 PST
Xref: gmd.de comp.std.c:3961 comp.std.c++:3478
Path: gmd.de!xlink.net!sol.ctr.columbia.edu!spool.mu.edu!bloom-beacon.mit.edu!gatech!europa.eng.gtefsd.com!uunet!decwrl!pa.dec.com!jit.dec.com!diamond
From: diamond@jit.dec.com (Norman Diamond)
Newsgroups: comp.std.c,comp.std.c++
Subject: Re: Legal Prototypes for the "main" Function
Date: 2 Sep 1993 01:02:31 GMT
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 77
Message-ID: <263gn7$2ui@usenet.pa.dec.com>
References: <2637nb$h30@crchh327.bnr.ca>
Reply-To: diamond@jit.dec.com (Norman Diamond)
NNTP-Posting-Host: jit533.jit.dec.com
Keywords: main function prototype C ANSI American National Standard X3.159-1989

In article <2637nb$h30@crchh327.bnr.ca> davisonj@bnr.ca (John M Davison) writes:
>Section 2.1.2.2.1 ("Program Startup") says that each of these two prototypes
>          int main(void);
>          int main(int numOfArgs, char *arrayOfArgs[]);
>The following prototype, however, would seem to be much more sensible:
>          int main(size_t numofArgs, const char * const * const arrayOfArgs);

The first const would not be sensible because programs are allowed to modify
the strings that the argv array elements point to, and the last const would
be gratuitous -- if other functions can modify their own variables that are
received as parameters, then why should main() be restricted?  Even you
didn't restrict the argc parameter that way.

The middle const would be sensible and its sole effect would be to require
rewriting of nearly all existing code.  (So now you know why that one was
omitted too.)

It might be sensible to make the argc parameter size_t instead of int, but
I think it will be a long (:-) time before we see operating systems that
permit passing more than 32767 strings in a command line, or invokers who
wish to pass such.

>        If I'm not calling "main" recursively or using it in any other funny
>manner, I would prefer the following:
>          static int main(size_t numofArgs,
>                          const char * const * const arrayOfArgs);

I think "static" would not be sensible, for the same reason as making the
declarations of library functions say "static" would not be sensible.
Pedantically, implementations could be made to work despite this misleading
formality of syntax (after all, they already do so with "static" functions
anyway), but why bother?

>        If I were calling it from, say, a POSIX.1 "exec..." call, I might
>prefer to use
>          static int main(int numofArgs,
>                          const char * const * const arrayOfArgs);

Returning argc's type to int instead of size_t, but otherwise identical to
your previous suggestion?  Your suggestions seem a bit incoherent.

>        Of course, I might also want to use other variations:
>        int main();

Allowed.

>        static int main();

Disallowed.

>        main();

Allowed.

>        A quick read through Section 2.1.2.2.1 would seem to indicate that the
>only two acceptable prototypes are the two I listed above.  Is this the case?

It is.

>        Is there any way to express the "constness" configuration of the
>"arrayOfArgs" parameter using the more readable "[]" syntax instead of all
>those *'s?

In the paragraphs defining the meaning of the "const" qualifier, yes.  But
again, if you try using such a declaration, then your program has undefined
behavior (though it is likely to work with most implementations).

>        Are the proposed C++ rules regarding the "main" prototype different
>than the C rules established in American National Standard X3.159-1989?

The proposed rules in Ellis & Stroustrop are the same as for C.  (This is
not necessarily the current answer.)
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
A program in conformance will not tend to stay in conformance, because even if
it doesn't change, the standard will.       Force = program size * destruction.
Every technical corrigendum is met by an equally troublesome new defect report.