what does this warning mean ?

[Richard Heathfield]

Martin Ambuhl said:

This warning is bogus and incorrect.

It's bogus, but not incorrect: int main() is indeed an old-style function
definition, and in any case any implementation can issue any diagnostics
it likes.

This warning is bogus and incorrect.

It's bogus, but not incorrect: int main() is not a prototype, so the
prototype for main (which is not required) is indeed missing, and in any
case any implementation can issue any diagnostics it likes. In this case,

This warning is bogus and incorrect.
Agreed.

This warning is bogus and incorrect.
Agreed.

Complain to Jacob. His compiler is broken.

Agreed.

 

[Keith Thompson]

3) Note that int main() defines a function that will take an
unspecified number of arguments. It does NOT mean that it is
a void function. C is NOT C++. The first warning is justified

In a function declaration that's not a definition, empty parentheses
indicate that the function takes an unspecified number and type of
arguments. But in a function *definition*, empty parentheses imply
that the function has no parameters.

4) int main() is NOT a function prototype. Second warning is
justified.
5) The correct prototype is int main(void). Third warning is
justified. The ANSI C Norm specifies explicitely that.

Just out of curiosity, why do you refer to ANSI C rather than ISO C?
The current C standard, C99, was issued by ISO; ANSI merely adopted
it.

There's a convoluted argument (I don't recall the details) that
'int main() { ... }' is invalid, but the general consensus is that
it's perfectly valid (though obsolescent).

[...]

 

[Francine.Neary]

Hi Ambuhl
You mean then that

int fn();

is the same as
int fn(void);

???

Note that

int fn() means a function with an UNSPECIFIED number of parameters!

But that wasn't what was in the original code. The original code went:

int main()
{
...
}

In a function DEFINITION like this, () is completely equivalent to
(void) (I remember looking it up once...)

You're right that in a DECLARATION, they are different:

int main(); /* main takes an unspecified number of parameters */
int main(void); /* main takes no parameters */

So the warning is indeed bogus and incorrect.

You mean then that

int fn() is a correct prototype?

This is completely WRONG.

But a definition serves as a prototype. I'd expect this warning to
mean I'd called a function with no prototype in scope, which isn't the
case here.

The definition of main is int main(void) or int main(int,char **)
not int main()

Exactly as above... in a DEFINITION, int main() is absolutely fine.
(As in just main() in C90.)

There. You have at least one hit!

Congratulations Mr Ambuhl. 1 out of 4 is quite a good progress for you.
Next time you will achive 2 wrongs for 2 correct. Keep on.

4 out of 4 and a gold sticker, I'd have said.

 

[jacob navia]

But that wasn't what was in the original code. The original code went:

int main()
{
...
}

In a function DEFINITION like this, () is completely equivalent to
(void) (I remember looking it up once...)

This is the definition of a function with an unspecified
number of arguments.

You're right that in a DECLARATION, they are different:

int main(); /* main takes an unspecified number of parameters */
int main(void); /* main takes no parameters */

So the warning is indeed bogus and incorrect.

I do not think so. But I am not a language lawyer.

But a definition serves as a prototype. I'd expect this warning to
mean I'd called a function with no prototype in scope, which isn't the
case here.

This means that main has no prototype since you did NOT
provide a prototype and main *IS* always called!

Exactly as above... in a DEFINITION, int main() is absolutely fine.
(As in just main() in C90.)

It is absolutely fine. It is just an obsolescent feature, and
if you do take the HIGHEST warning level you get that warning!

Do not like it?

Then call the compiler with no special warning level and you see no
warnings. Under the HIGHEST warning level I will warn about obsolescent
features. What's wrong with that?

 

[jacob navia]

Heinrich Pumpernickel wrote:
[snip]

gcc prints no warnings .

gcc misses a warning for an incorrect definition
of the 'main' function then.

What's incorrect about the main() definition?

You're correct that the only valid prototypes are int main(void) or int
main(int, char**). A prototype is not /required/ to be provided, however.

int main() is ugly and obsolescent. But it is not (yet) incorrect.

Under the highest warning level, a compiler should warn
about

int main()

since it is an obsolete syntax. Note that lcc-win does NOT
warn in the default warning level.

 

[Martin Ambuhl]

Hi Ambuhl
You mean then that

int fn();

is the same as
int fn(void);

???

No. Nowhere did I say that. Why would you even suggest that I "meant"
something that I did not in anyway address.
There is nothing to warn about.
There is nothing "old-style" about it.
The diagnostic is an editorial statement of personal preference on the
part of the compiler writer and suggests a problem where there is none.
The warning is bogus. It is wrong. While Jacob's compiler is free to
emit what ever bogus diagnostics it wants to, that it does so makes it
broken as far as any serious user is concerned.

Note that

int fn() means a function with an UNSPECIFIED number of parameters!


You mean then that

int fn() is a correct prototype?

This is completely WRONG.


The definition of main is int main(void) or int main(int,char **)
not int main()


There. You have at least one hit!

Congratulations Mr Ambuhl. 1 out of 4 is quite a good progress for you.
Next time you will achive 2 wrongs for 2 correct. Keep on.

As usual, Jacob, you are full of it. If you continue to prove that you
are completely ignorant, you may convince us not to bother with
lcc-win32 as well.

 

[jacob navia]

Even for the former Standard, jacob should refer to the ISO Standard.
ANSI should not be relevant to him, because he's a Frog.

Richard

You are a typical slave of HMQ (her majesty the queen).

I am not a frog. I live in a country where some people
eat parts of frogs. "Nuance"

 

[Richard Bos]

Just out of curiosity, why do you refer to ANSI C rather than ISO C?
The current C standard, C99, was issued by ISO; ANSI merely adopted
it.

Even for the former Standard, jacob should refer to the ISO Standard.
ANSI should not be relevant to him, because he's a Frog.

Richard

 

[Martin Ambuhl]

Heinrich Pumpernickel wrote:
[snip]

gcc prints no warnings .

gcc misses a warning for an incorrect definition
of the 'main' function then.

Ignore Jacob. He hasn't a clue.

 

[Keith Thompson]

Even for the former Standard, jacob should refer to the ISO Standard.
ANSI should not be relevant to him, because he's a Frog.

That kind of epithet is uncalled for.

 

[Francine.Neary]

This is the definition of a function with an unspecified
number of arguments.




I do not think so. But I am not a language lawyer.

Do you think it might be a good idea to become a language lawyer if
you're maintaining a compiler?

I looked it up again:

(6.5.4.3) An empty list in a function declarator that is part of a
function definition specifies that the function has no parameters. The
empty list in a function declarator that is not part of a function
definition specifies that no information about the number or types of
the parameters is supplied.

This means that main has no prototype since you did NOT
provide a prototype and main *IS* always called!

(6.7.1) If the declarator includes a parameter type list... such a
declarator also serves as a function prototype for later calls to the
same function in the same translation unit.

Now you need to observe that the empty list is a list...

It is absolutely fine. It is just an obsolescent feature, and
if you do take the HIGHEST warning level you get that warning!

Do not like it?

Then call the compiler with no special warning level and you see no
warnings. Under the HIGHEST warning level I will warn about obsolescent
features. What's wrong with that?

Nothing wrong with that, but why not say "int main() is obsolescent
syntax" (which has the benefit of being true), rather than "int
main()' is a non-ANSI definition" (which has the drawback of being
false)?

(Note well that obsolescent != obsolete.)

 

[Richard Bos]

[...]
5) The correct prototype is int main(void). Third warning is
justified. The ANSI C Norm specifies explicitely that.
Just out of curiosity, why do you refer to ANSI C rather than ISO C?
The current C standard, C99, was issued by ISO; ANSI merely adopted
it.

Even for the former Standard, jacob should refer to the ISO Standard.
ANSI should not be relevant to him, because he's a Frog.

You are a typical slave of HMQ (her majesty the queen).

And you are illiterate, where headers are concerned. I'm a subject of
Hare Majesteit de Koningin, not of Her Majesty the Queen.

(My point would have stood as strongly if _you_ had been a subject of
either: we're all in Europe, not in the USA. ANSI is irrelevant to both
of us.)

Richard

 

[Richard Heathfield]

Richard Bos said:

And you are illiterate, where headers are concerned.

Indeed he is.

I'm a subject of
Hare Majesteit de Koningin, not of Her Majesty the Queen.

Indeed you are.

(My point would have stood as strongly if _you_ had been a subject of
either: we're all in Europe,

Speak for yourself!

not in the USA. ANSI is irrelevant to both of us.)

Technically you're correct, but I don't think it's really such a big deal.
ANSI were the first national standards body to produce a C standard, and
the first conforming compilers all claimed ANSI conformance, not ISO
conformance. K&R2 has "ANSI C" plastered over the cover. It's hardly
surprising if people refer to standard C as "ANSI C". I'd rather save
pickiness for where it matters - such as, for example, not classifying the
UK as part of Europe. The English Channel is there for a reason.

 

[Joachim Schmitz]

I'd rather save
pickiness for where it matters - such as, for example, not classifying the
UK as part of Europe. The English Channel is there for a reason.

You mean the Frensh Channel?

And believe it or nor, the UK is part of Europe, it is not a continent of
it's own and is even a member in the EU (still)

Bye, Jojo

 

[Joachim Schmitz]

You mean the Frensh Channel?

And believe it or nor, the UK is part of Europe, it is not a continent of
it's own and is even a member in the EU (still)

s/in/of/g

Bye, Jojo

 

[Richard Heathfield]

Joachim Schmitz said:

You mean the Frensh Channel?

Nope. I can read a map, same as anyone, and on my map of the universe it is
clearly marked as the English Channel. I don't object to calling it the
South Sea, though, if you'd prefer to do that.

And believe it or nor, the UK is part of Europe, it is not a continent of
it's own and is even a member in the EU (still)

I'm glad you think so. Just so long as Europe stays on its side of the
water, you can think what you like.

 

[Richard]

Richard Bos said:


Indeed he is.

"Indeed", you can't resist can you? If you are going to killfile Jacob
then have the strength of character not to bitch and whine about him on
other peoples replies. You are responsible for more OT preening and
strutting than all the rest that you complain so audibly about when
things don't go your way. Maybe it is time for the killfile to be dusted
off.

 

[Army1987]

Keith Thompson said: [unsnip]

Well, partly. It certainly isn't "non-ANSI" (though why the messages
refer to ANSI rather than ISO is a mystery). But 'int main()' rather
than 'int main(void)' is an old-style declaration, and C99 6.11.6
says:

The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.

Indeed. Nevertheless, it remains a feature.

Well, it doesn't make the third of those warnings correct, but it
does cause the first or the second of them non-bogus. I don't
think it is bogus to issue a warning for the use of obsolescent
features. (But issuing *both* warnings *is* bogus, as they say
almost exactly the same thing; and if the warning read "function
declarations with empty parentheses are an obsolescent feature" it
would be more useful.)
Anyway, the warning "printf argument mismatch for format i.
Expected long int got int" is totally wrong. It doesn't make lcc
broken by itself (the standard allows an implementation to issue
whatever diagnostics it likes, without even requiring them to be
true), it just hugely lowers the quality of implementation,
#ifdef FLAME
(but in the case of lcc-win32 it is difficult to make it much
lower than it would be, even without that spurious warning...)
#endif
but anyway lcc-win32 is broken for other reasons, too. (Choosing
an ISO C standard header at random, reading the one lcc-win32
provides, and failing to see anything wrong with it is not a very
easy task.)

 

[Eric Sosman]

You mean then that

int fn();

is the same as
int fn(void);

???

That's not the situation for which the compiler
issued the misleading messages.

int fn() { return 0; )

and

int fn(void) { return 0; }

define the fn function identically, even though they
declare it differently.

In a response to Francine Neary you write of the
original `int main() { ... }' that

> This is the definition of a function with an unspecified
> number of arguments.

.... but that's wrong. The function is defined with no
arguments at all. It is declared as taking an unspecified
(fixed) number of arguments, but it is defined as taking
none. Would you maintain that

int main(argc, argv)
int argc;
char **argv;
{ ... }

.... is the definition of a function with an unspecified
number of arguments?

Or again, consider a program of two compilation units:

/* module 1 */
int f(void);
int g();
int main(void) { return f() + g(); }

/* module 2 */
int f() { return 0; }
int g(void) { return 0; }

Is there a conflict between the declarations in module 1
and the definitions in module 2? If you see any, please
cite the relevant passage(s) from the Standard.

 

[Eric Sosman]

Under the highest warning level, a compiler should warn
about

int main()

since it is an obsolete syntax. Note that lcc-win does NOT
warn in the default warning level.

That is a reasonable goal, and I have no objection to
a compiler that issues a reasonable warning. But what would
you think of a compiler whose warning for this usage was

*** warning: possible loss of precision
or
*** warning: arguments to main() should be
declared `volatile'
or
*** warning: the Hundred Years' War actually
lasted 116 years

? I applaud the compiler's attempt to warn, but I deplore
its use of misleading or downright incorrect messages.