>> GCC itself relies on wrapv semantics. As does glibc. And >> coreutils. And GNU tar. And Python. I'm sure there are >> many other significant programs. I don't have time to do a >> comprehensive survey right now. > > Where does GCC rely on that? I don't see it anywhere?
It's not like the code has big waving robot arms next to a comment that says "Danger, Will Robinson!". It's usually more subtle. But since you asked, I just now did a quick scan of gcc-4.3-20061223 (nothing fancy -- just 'grep -r') and the first example I found was this line of code in gcc/stor-layout.c's excess_unit_span function: /* Note that the calculation of OFFSET might overflow; we calculate it so that we still get the right result as long as ALIGN is a power of two. */ unsigned HOST_WIDE_INT offset = byte_offset * BITS_PER_UNIT + bit_offset; Here, the programmer has helpfully written a "Danger, Will Robinson!" comment, which is how I found this example so quickly. Typically, though, we won't be so lucky. I'd guess there are dozens, maybe hundreds, of cases like this in the GCC sources. In many cases the problem won't be obvious. Or if we see something suspicious, it won't be immediately obvious whether the potential problem is real. For example, I haven't checked whether the above code is a real problem, though that comment certainly suggests so. (I suppose the comment might be incorrect, but if so then that's a different bug.) > If you can point out specific spots, please file a bug and I will go > and fix them. Thanks, but it's a lot of work to find bugs like this. Particularly if one is interested in finding them all, without a lot of false alarms. I don't have time to wade through all of GCC with a fine-toothed comb right now, and I suspect nobody else does either. Nor would I relish the prospect of keeping wrapv assumptions out of GCC as other developers make further contributions, as the wrapv assumption is so natural and pervasive.