> I started looking through the llvm-gcc vs. clang comparisons, and > noticed that in > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/A9/A9AB5AE7.c > , size_t is declared incorrectly. Any idea how that might have > happened?Hi Eli, Thanks for pointing this out, I'll look into this tonight. However I can give you the quick generic answer right now (of course you already know it) which is that real C code does just about anything that can be parsed :). If LLVM warns about this incorrect definition I can eliminate this kind of test case, I'll look into this as well. John
On Wed, Jan 20, 2010 at 12:05 PM, John Regehr <regehr at cs.utah.edu> wrote:>> I started looking through the llvm-gcc vs. clang comparisons, and >> noticed that in >> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/A9/A9AB5AE7.c >> , size_t is declared incorrectly. Any idea how that might have >> happened? > > Hi Eli, > > Thanks for pointing this out, I'll look into this tonight. > > However I can give you the quick generic answer right now (of course you > already know it) which is that real C code does just about anything that can > be parsed :).Of course, but this looks like the declaration of memset came from a system header.> If LLVM warns about this incorrect definition I can eliminate this kind of > test case, I'll look into this as well.clang warns and doesn't treat the usual declaration of memset as the C library memset if size_t is wrong; gcc apparently doesn't care. -Eli
> Of course, but this looks like the declaration of memset came from a > system header.Argh, my fault-- I let some files preprocessed on a 64-bit host sneak into the harvesting run. I'll get rid of them for the next run. John
> clang warns and doesn't treat the usual declaration of memset as the C > library memset if size_t is wrong; gcc apparently doesn't care.Eli-- I looked at this code a bit more closely and it seems to me that (in this particular case, by luck) the gcc strategy of ignoring the problem is OK. Clang wants size_t to be an unsigned int, whereas in these files, size_t is an unsigned long. I can't think of any observable difference between these two types on x86-clang. Anyway this doesn't form an argument that clang should relax its rules, but it does indicate that gcc is probably not doing anything too silly. John