kenner@xxxxxxxxxxxxxxxxxxx (Richard Kenner) writes: > A few comments: Thanks for the quick review. >> Many portable C programs assume that signed integer overflow wraps around >> reliably using two's complement arithmetic. > > I'd replace "portable C programs" with "widely-used C programs". The normal > use of "portable" means that it conforms to the standard. I was looking for an adjective that mean the programs work on a wide variety of platforms, and "portable" seems more appropriate than "widely-used". To my mind "portable" means "can be transported", which is a broader category than "conforms to a standard". For example, <http://en.wikipedia.org/wiki/Porting> mentions both ISO standards and GCC as alternative methods of producing portable software. (It also mentions Autoconf! Wikipedia rules. :-) >> Conversely, in at least one common case related to overflow, the C standard >> requires behavior that is commonly not implemented. > > To what does this refer, the (x * 10 / 5) case? No, INT_MIN % -1. Thanks, I'll reword it. >> This is guaranteed by the C standard and is portable in practice, unless >> you specify aggressive optimization options suitable only for special >> applications. > > Not sure what the ", unless" part means. I was referring to the aggressive optimization options mentioned in the earlier thread for non-GCC compilers, which result in nonconforming (but presumably faster) implementations where unsigned overflow does not wrap around reliably. >> Rewriting code in this way will be inconvenient, though, particularly if >> the signed values might be negative. Also, it will probably hurt >> performance. > > Why would it hurt performance? Lots of reasons, e.g., when the type in question isn't apriori known (it's off_t, say) and you have to substitute a possibly-wider unsigned type without a lot of Autoconf magic that most people won't bother with. However, I'll tone down the wording. > if you bury it in macros, it isn't even particularly inconvenient. Even for off_t and so forth? I'll have to see that.... >> If your code uses an expression like @code{(i * 2000) / 1000} and you >> actually want the multiplication to wrap around reliably, put the >> product into a temporary variable and divide that by 1000. This >> inhibits the algebraic optimization on many platforms. > > I'd be dubious about including this. Yes, I was a bit dubious too, which is why I asked. But... > The chance of somebody actually neededing wraparound semantics on such an > expressions strikes me as vanishingly small I'm afraid it's not that small, as that method (assigning to a temporary so that the compiler doesn't over-optimize due to signed overflow assumptions) is used in many real-world applications, partly because it works, and partly I suppose by analogy from 'double'. (Sigh. Now you'll probably want me to go find instances of that, too. Do I get extra points for finding an instance in GCC? :-) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
