http://d.puremagic.com/issues/show_bug.cgi?id=1977
------- Comment #8 from [EMAIL PROTECTED] 2008-11-22 11:04 ------- (In reply to comment #6) > (In reply to comment #4) > > It's not ridiculous at all. The compiler cannot tell what values > > will be possibly passed to f, and the range of byte and short are > > sufficiently small to make overflow as frequent as it is confusing > > and undesirable. > > I disagree: > - Read comment 3. How can adding (or even subtracting, multiplying or > dividing) two numbers in the range [-128, 127] possibly produce a value > outside > the range [-32768, 32767]? Sorry. Indeed, that is a good reason to keep the bug opened. > - If you're using (u)byte/(u)short, it follows that you should know what > you're > doing. Especially if you're doing it in an initialiser of something declared > explicitly as one of these types, in which case you've shown that you know > what > you're doing. Often, a 8/16-bit int comes from a need to minimize occupied storage in a larger structure, to conform to some format etc. I do agree that often people operating with such structures/in such environments do know what they're doing, but that doesn't mean that implies they must increase their attention. Knowing what they're doing, they'll insert a cast. > - It happens even in the case of bitwise operations (&, |, ^, >>, >>>, but > strangely not ~), by which overflow is impossible. It might be sensible for > <<, but no more. The plan is to have sensible bitwise operations preserve the size of their operands. Only arithmetic and shift will "spill" into larger types. --