[cfe-dev] Implicit function declaration warnings

[Eli Friedman]

On Tue, Aug 19, 2008 at 7:15 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote:
> Hi all,
>
> I was wondering why my frontend wasn't generating any warnings where I
> expected them and had a look at the source. I found something typical where
> implicit function declarations are concerned.
>
> In Sema/SemaDecl.cpp, in Sema::ImplicitlyDefineFunction, a diagnostic is
> generated for implicit declarations. When not in C99 mode, this works as
> expected, a diagnostic of type diag::warn_implicit_function_decl is generated
> which is enabled through -Wimplicit-function-declaration.
>
> However, when in C99 mode implicit declarations no longer generate a normal
> warning, but an extension warning of type diag::ext_implicit_function_decl.
> This is a bit weird (since, if I read the warning correctly, an implicit
> function declaration should be an error in C99 mode), but I that ignoring this
> new constraint in C99 is a gcc "feature".
>
> Anyway, this means that when I compile in C99 mode, I won't get implicit
> function declaration warnings, even when I explicitely specify
> -Wimplicit-function-declaration. This is of course unexpected and, IMHO
> unwanted.

That warning should probably be using the new EXTWARN diagnostic
category, which should give the desired behavior.

> I've attached a patch which makes clang explicitly map the
> diag::ext_implicit_function_decl diagnostic type as a WARNING, when
> -Wimplicit-function-declaraton is given. This has the desired effect, though
> I'm not completely sure that this is the right approach. In particular, the
> error messages is now slightly confusing, it says:
>
> foo.c:21:3: warning: implicit declaration of function 'printf' is invalid in C99
>
> Thinking a bit more on this, it seems this stuff is mainly caused by clang
> supporting gcc's extensions out of the box. IMHO it would be better to be able
> to toggle these extensions seperately, and giving errors for extensions not
> enabled, or giving warnings for extensions that are enabled only when
> -pedantic is given.

The philosophy behind the current design of the -pedantic option
follows that of gcc's corresponding option: -pedantic basically just
causes EXTENSION warnings to be printed.  Of course, it's trivial to
implement something like -pedantic-errors; it's just a matter of
making the errors fatal.

Independent of -pedantic, there's are supposed to be some differences
between -std=c99 and -std=gnu99 modes, which mostly aren't implemented
in clang yet.  This roughly maps to GNU extensions which cause code to
have different meanings vs. standard C.  A few examples (based off of
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/C-Dialect-Options.html#C-Dialect-Options):
on Linux, gcc defines "linux" in gnu99 mode, but not in c99 mode; gcc
doesn't recognize typeof in c99 mode.

And then, independent of that are the one-off warning enable/disable
options, like Wimplicit-function-declaraton, which allow more
fine-grained control over warnings.

Of course, we don't need to follow gcc's design exactly, but in
general, I think it's reasonably well designed.  The only real
restrictions for clang are that we must have some sort of loose mode
that doesn't print warnings for commonly used GNU extensions (like
gcc's -std=gnu99), and should have some sort of mode that's a
"conforming implementation" per the C99 definition of a conforming
implementation (something like gcc's -std=c99 -pedantic).

-Eli