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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
