c/393: Implicit function declaration bugs

[Joseph Myers]

>Number:         393
>Category:       c
>Synopsis:       Implicit function declaration bugs
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 09 06:16:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Joseph S. Myers
>Release:        2.96
>Organization:
none
>Environment:
System: Linux decomino 2.2.16 #1 Thu Jun 8 00:26:22 UTC 2000 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
>Description:

Current GCC CVS has some bugs related to the handling of implicit
function declarations.  See
<URL: http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00262.html >,
testcases c90-impl-decl-1.c and c99-impl-decl-1.c and discussion below.

>How-To-Repeat:

With -std=iso9899:1990 -pedantic-errors, implicit function
declarations (ISO/IEC 9899:1990 subclause 6.3.2.2) are legitimate,
should be accepted, and generally are.  However, GCC wrongly rejects
them for builtin functions even when they are correct.  7.1.7 says:

    Provided that a library function can be declared without reference
    to any type defined in a header, it is also permissible to declare
    the function, either explicitly or implicitly, and use it without
    including its associated header.  If a function that accepts a
    variable number of arguments is not declared (explicitly or by
    including its associated header), the behavior is undefined.

For example, the code from the testcase c90-impl-decl-1.c

    int bar (const char *a, const char *b) { return strcmp (a, b); }

is legitimate, and should not receive a warning.  (Warnings where the
implicit declaration is wrong (e.g. for abort()), and warnings anyway
with -Wall (but not pedwarns if the implicit declararion is correct),
and pedwarns in C99 mode, should remain.)


With -std=iso9899:1999, any implicit function declaration should
receive a warning (becoming an error with -pedantic-errors).  For
example,

    void foo (void) { bar (); }

from c99-impl-decl-1.c fails to receive any diagnostic with
-std=iso9899:1999 -pedantic-errors, but should be an error.

This would need to interact in some sensible way with the existing
-Wno-implicit-function-declaration and related options, including with
option orderings such as "-pedantic-errors
-Wno-implicit-function-declaration -std=iso9899:1999".

>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: