CBFalconer said:
I am quoting the following text from the standard(section 5.1.2.2.1).
I have removed the examples for clarity...
[snip]
I was interpreting the "It shall defined...." as the "program can have
forms A(int main(void){}) or B(int main(int argc, char *argv[]) {}) or
C(some other implementation-defined manner)"...
I want to know if the clause implies "int main(void){} or int main(int
argc, char *argv[]) {} or some other implementation-defined manner"
must be supported by the implementation or "int main(void){} and int
main(int argc, char *argv[]) {} and some other implementation-defined
manner" must be supported by the implementation?
I think you meant to quote the following:
5.1.2.2.1 Program startup [snip]
[#1] The function called at program startup is named main.
The implementation declares no prototype for this function.
It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv,
though any names may be used, as they are local to the
function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent;8) or in some other implementation-defined
manner.
which says that the two listed versions are correct. An
implementation may also allow some other startup call, which cannot
be portable, and thus should be avoided.
Yes, I'm sure he did mean to quote that section. And, in fact, he
did, omitting portions that were irrelevant to his question. So why
did you repeat it?
I think he came up with a rather unusual interpretation of that
section, one that I think is actually consistent with the wording.
Specifically, the interpretation is that an implementation must permit
int main(void) { /* ... */ }
*or* it must permit
int main(int argc, char *argv[]) { /* ... */ }
*or* some other implementation-defined definition. So one
implementation might support the zero-argument form (and reject
anything else), and another implementation might support the
two-argument form (and reject anything else), and so on. So the
question is whether the "or" implies a choice for the implementation
(to which the programmer must conform), or a choice for the programmer
(which the implementation must support either way).
Now I'm sure beyond reasonable doubt that that wasn't the intent, and
the "correct" interpretation (that an implementation must support both
forms, and a program can use either) is also consistent with the
wording. But the alternative interpretation isn't entirely
nonsensical; after all, the idea that the environment can call a
function that might have either of two declarations is itself rather
odd, and the allowance for implementation-defined definitions already
means that a program that's valid for one implementation might be
rejected by another.