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

[Richard Kenner]

> >> Many portable C programs assume that signed integer overflow wraps around
> >> reliably using two's complement arithmetic.
> >
>
> 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".

Maybe just say what you mean, then:  "Many C programs that work on a wide
variety of platforms assume that ..."

> 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.  

Which means that, at best, "portable" is ambiguous.  To me, however, I'd
associate it with conformance, so that it would mean "can be transported
due to compliance with a standard".  Since you are looking for a specific
meaning, I suggest simply saying that meaning rather that trying to find
a word to summarize it and run the risk of it meaning different things
to different people.

> 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.

I'd suggest making it clearer that any such compiler that did that is
noncomforming.

> 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. 

True.  However, I have to say that the idea of having a program in which
off_t values overflow is scary, to say the least!  It strikes me as very
bad programming practice.

> >> 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.
> >
> > 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'.

I'm not talking about the METHOD here, but about the likelihood that somebody
would actually WANT to compute the value ((i * 2000) mod 2**32) / 1000.

As to the method, however, I disagree with suggesting it because the
difference between compiler-generated temporaries and user temporaries is
getting smaller and smaller. I don't think it's worked for 'double' in years.