[cfe-commits] r135075 - in /cfe/trunk: lib/Analysis/FormatString.cpp test/Sema/format-strings-i386.c

[Ted Kremenek]

All fair comments.  I had similar reservations, and was borderline on reverting this myself.

The motivating example was something like

  typedef unsigned long UInt32;

in a system header, but only for i386.

I'll revert.

On Jul 14, 2011, at 9:34 AM, David Blaikie wrote:

> I have to question the wisdom of this approach at all. Warnings should
> help to write good code, even if it may happen to work in a few cases.
> When int and long are the same size, then we have incorrect code that
> happens to work. I think we should leave this warning on and encourage
> users to make their code correct so that it doesn't break when they move
> to an LP64 environment.
> 
> I tend to agree - I do have some amount of pain working with a compiler (MSVC) & on a team that produces multi-architecture binaries, getting warnings (when we use warnings-as-errors, and thus break the build) in certain flavors that aren't shown in others can be quite a pain. Though I can somewhat understand that people aren't necessarily used to such pedantry & this might need some way to differentiate itself as a different class of warning.
> 
> (one of the weirder ones I've seen on MSVC is that I don't get sign mismatch between size_t and int on 64 bit (I assume because size_t is 64 bit unsigned on a 64 bit build, so int can implicitly convert to a 64 bit unsigned value) but on 32 bit you get a sign mismatch warning/error/build break) 
> 
> - David
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110714/efc5f454/attachment.html>