[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]

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.