[llvm-bugs] [Bug 33224] New: clang places implicitly declared C functions at compile unit scope

via llvm-bugs llvm-bugs at lists.llvm.org
Tue May 30 06:52:30 PDT 2017


            Bug ID: 33224
           Summary: clang places implicitly declared C functions at
                    compile unit scope
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: momchil.velikov at arm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18537
  --> https://bugs.llvm.org/attachment.cgi?id=18537&action=edit

Compiling the following testcase with `clang -std=c90 -c x.c`

> int f() {
>        g();
>        return 0;
> }
>  int (*p)() = g;

completes successfully.

The identifier `g` is not declared at the place, where it appears in the
context of the function call expression. In that case, the C90 Standard says
( Function calls):

>     If the expression that precedes the parenthesized argument list in a function
>     call consists solely by an identifier, and if no declaration is visible for this
>     identifier, the identifier is implicitly declared as if, in the innermost block
>     containing the function call, the declaration
>     extern int identifier();
>     appeared.

Therefore, the above program should be equivalent to:

> int f() {
>        extern int g();
>        g();
>        return 0;
> }
>  int (*p)() = g;

for which clang terminates with an error. The C90 Standard ( Scopes of
identifiers), says:

> If the declarator or type specifier that declared the identifier appears inside a block [...],
> the identifier has block scope, which terminates at the } that closes the associated block.

so, this should be the correct behavior in both testcases.

However, clang places the implicitly declared function at translation
unit scope, which causes the identifier to be visible in the initializer
in the original testcase, in effect accepting an invalid program.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170530/e9dfb31e/attachment.html>

More information about the llvm-bugs mailing list