------- Additional Comments From joseph at codesourcery dot com 2005-03-08
18:59 -------
Subject: Re: New: Lame error message for undefined type
On Tue, 8 Mar 2005, falk at debian dot org wrote:
> % cat test.c
> unknowntype f() { return 0; }
>
> % gcc -c test.c
> test.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f'
>
> Firstly, since this is a frequent mistake, we should really be able to produce
> "unknowntype used like a type", as other compilers do.
>
> Secondly, IMHO this kind of "expected ..." error message is *never* a good
> idea. I cannot recall a single instance where it was actually helpful to me,
> and very often, as in this case, it is extremely confusing, and I would be
> better off with plain "syntax error before f" as it used to be in the old
> parser. Even though my knowledge of C parsing is probably slightly above
> average, I have not the slightest idea why the parser expects '=', ',', ';',
> 'asm' or '__attribute__' here, and what I can derive from that about the
> mistake I made. But maybe that's just me.
Functions can be defined without declaration specifiers in C90. GNU C
also allows (but pedwarns for) definitions (at file scope) of objects with
no declaration specifiers (for example, "*foo;" meaning "int *foo;"). So
"unknowntype" has been parsed as the name being declared at this point.
So it must either be a function definition of a function called
"unknowntype" (which it isn't as the declaration isn't a function one) or
a data declaration, and the tokens listed are those which would follow
"unknowntype" in a data declaration (for example, "unknowntype = 1; f()
...").
It would be possible to have special-case detection for where empty
declaration specifiers are followed by a declarator consisting only of an
identifier, unparenthesised, and in the case of a parse error act like
that identifier was a type and look for a new declarator. This would
cover "unknowntype foo;" and "unknowntype *foo;". You can't detect
undeclared types in full generality; for example,
unknowntype (foo)() { return 0; }
is syntactically valid C90 which should be diagnosed, as it is at present,
as declaring a function "unknowntype" returning a function and so breaking
a constraint, rather than the compiler second-guessing that "unknowntype"
is a type and "(foo)" is the parenthesised function name.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
