On 12/14/2016 04:56 PM, Bruno Haible wrote: > Hi Paul, > > Possibly dumb questions, but: >> over time I am >> becoming more inclined to like the Emacs model, where object counts are >> typically kept as nonnegative but signed integers. This approach makes C >> code a bit more reliable, as compiling with -fsanitize=undefined is more >> likely to catch integer overflow errors in index calculations (a real >> problem nowadays). > > Are you saying that -fsanitize=undefined or -fsanitize=signed-integer-overflow > (or -ftrapv, when using an older GCC) can detect integer overflow for signed > integers, whereas no such option exists and won't exist for unsigned integers > (because there are so many pieces of code that intentionally do a mod-2^32 > or mod-2^64 computation on unsigned integers?
The C standard states that there is no such thing as ill-behaved integer overflow in unsigned numbers: operations are well-defined to wraparound modulo 2^width. It is only signed integers where there is implementation-defined behavior (whether that behavior is wraparound, saturation, raising a trap, or something else), and thus where there is implementation leeway for implementing flags like -ftrapv for controlling that behavior in a beneficial manner. It is still possible to compute whether an unsigned operation would overflow, you just can't convince the compiler to do it for you, so it becomes more verbose. > > And what about the gnulib 'xsize' module for checked size_t computations? As long as the manual checks are correct, it should be fine. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
