Re: Autoconf manual's coverage of signed integer overflow & portability

[Paul Eggert <eggert at CS dot UCLA dot EDU>]

kenner@vlsi1.ultra.nyu.edu (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?  :-)