[cfe-commits] r64504 - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ lib/AST/ lib/Analysis/ lib/CodeGen/ lib/Sema/ test/Analysis/ test/CodeGen/ test/Sema/
Neil Booth
neil at daikokuya.co.uk
Fri Feb 13 21:11:11 PST 2009
Chris Lattner wrote:-
> On Feb 13, 2009, at 7:10 PM, Daniel Dunbar wrote:
>
> > Nice, very very nice.
> >
> > Unfortunately, this is also causing us to reject quite a few of the
> > applications in the LLVM test-suite. I haven't had time to diagnose
> > the exact issues, but I think we are going to need to be more
> > accepting of other definitions of builtins. For example:
> > --
> > char *malloc();
> > void *f0() { return malloc(4); }
> > --
> >
> > Can you take a look?
>
> It's not clear to me that we should do this. Before the patch, we
> would have code that "worked with with GCC" get silently miscompiled
> with clang. Now we have code that "works fine with gcc" get
> "summarily rejected by clang". This is a big step forward in some ways.
>
> I guess it is bad that we don't accept some programs we used to, but
> is this really such a bad thing? If this just affects stuff in llvm-
> test, I'm inclined to just fix the programs. If this occurs in some
> large C code bases, then perhaps we should try to be more lenient.
The C standard reserves malloc (etc.) as an identifier with external
linkage. So I agree that Clang should feel able to reject
redeclarations with incompatible protoypes. I'd even argue it
*should* reject them.
There should probably be a test that uses of such identifiers other
than in the reserved sense is ok, e.g. as static local or as a
parameter name. Static file-scope should be rejected of course.
Neil.
More information about the cfe-commits
mailing list