«

On 27/08/2012 19:38, James Kuyper wrote:
> On 08/27/2012 01:11 PM, Vincenzo Mercuri wrote:
>> On 27/08/2012 18:27, James Kuyper wrote:
>>> On 08/27/2012 10:36 AM, lovecreatesbeauty wrote:
>>> ...
>>>> ... I meant in my previous message the following is valid C++ but illegal C.
>>>>
>>>> int main() { /* ... */ }
>>>
>>> What gives you that impression? What rule do you think it breaks?
>>>
>>
>> I think it is implementation-defined whether it is supported or not,
>
> Citation, please?

When the Standard says (N1570 5.1.2.2.1p1):

(...) 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;10) or in some other implementation-defined manner.

footnote 10):
Thus, int can be replaced by a typedef name defined as int,
or the type of argv can be written as char ** argv, and so on.

Given that I don't think that "int main(void)" and "int main()" are
"equivalent", my claim that "it is implementation-defined whether it is
supported or not" is taken into account by the phrase "or in some other
implementation-defined manner".


>
>> even though almost all the implementations do support it. But I'd say
>> that it is not the "most portable" way to define main.
>
> The standard describes two ways of defining main(), and requires every
> conforming implementation of C to support any definition of main
> equivalent to one of those two ways. This form is not the same as either
> one of those, but it is equivalent to the first of those two ways.
[..]

That's the point. If you say that "int main(void)" is equivalent to
"int main()" then you are saying that it is also equivalent to
"int main(int argc, char **argv, char **env)" or "int main(int argc)",
but I'm not convinced that compilers are obliged to support all these
definitions.


--
Vincenzo Mercuri

Am 27.08.2012 21:48, schrieb Vincenzo Mercuri:
> That's the point. If you say that "int main(void)" is equivalent to
> "int main()" then you are saying that it is also equivalent to
> "int main(int argc, char **argv, char **env)" or "int main(int argc)",
> but I'm not convinced that compilers are obliged to support all these
> definitions.

No "int main()" is equivalent to "int main(void)" for
definitions. There is this extra rule for definitions (versus just
declarations) such that these two are equivalent.

Jens

On 27/08/2012 21:54, Jens Gustedt wrote:
> Am 27.08.2012 21:48, schrieb Vincenzo Mercuri:
>> That's the point. If you say that "int main(void)" is equivalent to
>> "int main()" then you are saying that it is also equivalent to
>> "int main(int argc, char **argv, char **env)" or "int main(int argc)",
>> but I'm not convinced that compilers are obliged to support all these
>> definitions.
>
> No "int main()" is equivalent to "int main(void)" for
> definitions. There is this extra rule for definitions (versus just
> declarations) such that these two are equivalent.
>

Thanks, then I must have missed that part, where I can find the
definition of this equivalence?

--
Vincenzo Mercuri

On 08/27/2012 03:56 PM, Vincenzo Mercuri wrote:
....
> Thanks, then I must have missed that part, where I can find the
> definition of this equivalence?

6.7.6.3p10: "The special case of an unnamed parameter of type void as
the only item in the list specifies that the function has no parameters."

6.7.6.3p14: "An empty list in a function declarator that is part of a
definition of that function specifies that the function has no parameters."

It doesn't directly say that the declarations are equivalent, but what
it says about what those declaration specify, is word-for-word identical
in both cases.

Il 27/08/2012 22:09, James Kuyper ha scritto:
> On 08/27/2012 03:56 PM, Vincenzo Mercuri wrote:
> ...
>> Thanks, then I must have missed that part, where I can find the
>> definition of this equivalence?
>
> 6.7.6.3p10: "The special case of an unnamed parameter of type void as
> the only item in the list specifies that the function has no parameters."
>
> 6.7.6.3p14: "An empty list in a function declarator that is part of a
> definition of that function specifies that the function has no parameters."
>
> It doesn't directly say that the declarations are equivalent, but what
> it says about what those declaration specify, is word-for-word identical
> in both cases.
>

Thank you

--
Vincenzo Mercuri

James Kuyper <> writes:
> On 08/27/2012 03:19 AM, lovecreatesbeauty wrote:
>> On Monday, August 27, 2012 4:04:57 AM UTC, Keith Thompson wrote:
>>> lovecreatesbeauty <> writes:
[...]
>> I saw some C++ code like
>>
>> void main()
>> {
>> /*...*/
>> }
>
[snip]
>
> I don't see any relevant differences between the two languages in this
> regard. Could you explain more fully how this constitutes an example of
> incompatibility between C and C++?

C++, unlike C, requires main to return int, even for
implementation-defined definitions.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jens Gustedt <> writes:
> Am 27.08.2012 21:48, schrieb Vincenzo Mercuri:
>> That's the point. If you say that "int main(void)" is equivalent to
>> "int main()" then you are saying that it is also equivalent to
>> "int main(int argc, char **argv, char **env)" or "int main(int argc)",
>> but I'm not convinced that compilers are obliged to support all these
>> definitions.
>
> No "int main()" is equivalent to "int main(void)" for
> definitions. There is this extra rule for definitions (versus just
> declarations) such that these two are equivalent.

Definitions also provide declarations.

This program contains a constraint violation:

int main(void) {
if (0) main(42);
return 0;
}

This one, I argue, is strictly conforming (its behavior would be
undefined if the call were executed).

int main() {
if (0) main(42);
return 0;
}

Thus the two definitions are not equivalent, unless you use a rather
loose definition of the word "equivalent".

On the other hand, I believe it was *intended* for `int main()` to be
valid; requiring the `void` keyword would have broken existing pre-ANSI
code.

But `int main(void)` (if you don't need argc and argv) is better for
newly written C programs.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Kenneth Brody <> writes:
> On 8/24/2012 7:12 PM, Steven G. Kargl wrote:
[...]
>> The name of the language is "Fortran". It's been Fortran since
>> the Fortran 1990 standard.
>
> Noted. Note, too, that the last time I programmed in it, it was spelled
> "FORTRAN".

<http://en.wikipedia.org/wiki/Fortran> shows the cover of a Programmer's
Reference Manual with the name "Fortran". It was published in 1956.

But there's more to it than that; see
<http://en.wikipedia.org/wiki/Fortran#Capitalization>.

[...]

Shall we get back to C now?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Am 28.08.2012 00:20, schrieb Keith Thompson:
> Jens Gustedt <> writes:
>> Am 27.08.2012 21:48, schrieb Vincenzo Mercuri:
>>> That's the point. If you say that "int main(void)" is equivalent to
>>> "int main()" then you are saying that it is also equivalent to
>>> "int main(int argc, char **argv, char **env)" or "int main(int argc)",
>>> but I'm not convinced that compilers are obliged to support all these
>>> definitions.
>>
>> No "int main()" is equivalent to "int main(void)" for
>> definitions. There is this extra rule for definitions (versus just
>> declarations) such that these two are equivalent.
>
> Definitions also provide declarations.

Yes. But the declaration that is given through the definition does not
necessarily follow the same rules as one provided by a
declaration-only.

As James has already cited upthread

6.7.6.3p14: "An empty list in a function declarator that is part of a
definition of that function specifies that the function has no parameters."

> This program contains a constraint violation:
>
> int main(void) {
> if (0) main(42);
> return 0;
> }
>
> This one, I argue, is strictly conforming (its behavior would be
> undefined if the call were executed).
>
> int main() {
> if (0) main(42);
> return 0;
> }

so this function is specified as not receiving any parameters, just as
the one with void. The definition in the standard for function
prototype is

A *function prototype* is a declaration of a function that declares
the types of its parameters.

(ARAIK there is no syntax specification for prototypes.)

So this is a prototype: as you said it is a declaration, and it
specifies the types of its parameters, here in particular that there
are none. So really this is equivalent to the "(void)"
definition/declaration.

> On the other hand, I believe it was *intended* for `int main()` to be
> valid; requiring the `void` keyword would have broken existing pre-ANSI
> code.

It is intended to be valid and it is valid.

> But `int main(void)` (if you don't need argc and argv) is better for
> newly written C programs.

agreed

Jens

Keith Thompson wrote:
> This one, I argue, is strictly conforming (its behavior would be
> undefined if the call were executed).
>
> int main() {
> if (0) main(42);
> return 0;
> }

Which language is this? There's some doubt about whether "int main()" is
valid in a hosted C implementation (although it seems to work well in
practice), and although it's legal in C++, the recursive call to main is
illegal in C++, so the program still doesn't conform properly.

--
ais523