Re: [bug #23996] arithmetic overflow when using -used

[James Youngman]

On Sun, Aug 24, 2008 at 8:47 AM, Andreas Schwab <address@hidden> wrote:
> "James Youngman" <address@hidden> writes:
>
>> Yes, this is undefined behaviour in terms of the ISO C standard.  But
>> if your comment accurately implies that there are actual systems
>> on which this technique fails to work then we have a widespread
>> problem;
>
> That is correct, many people get that wrong.  Undefined behaviour means
> that it is impossible to predict the result.
>
>> including at least GNU tar
>
> Then it needs to be fixed.
>
>> and I think also gnulib and coreutils.
>
> The authors of gnulib and coreutils are well aware of the problem.
>
>> See in particular the Texinfo documentation for Autoconf.
>
> Please expand.

Well there's an entire section on it.

<<
@node Integer Overflow
@section Integer Overflow
@cindex integer overflow
@cindex overflow, signed integer
@cindex signed integer overflow
@cindex wraparound arithmetic

In practice many portable C programs assume that signed integer overflow wraps
around reliably using two's complement arithmetic.  Yet the C standard
says that program behavior is undefined
[...]
Despite this requirement by the standard, it has long been common for C
code to assume wraparound arithmetic after signed overflow, and all
known practical C implementations support some C idioms that assume
wraparound signed arithmetic, even if the idioms do not conform
strictly to the standard.  If your code looks like the following
examples it will almost surely work with real-world compilers.
[...]

In the following example, derived from the @acronym{GNU} C Library 2.5
implementation of @code{mktime} (2006-09-09), the code assumes
wraparound arithmetic in @code{+} to detect signed overflow:

@example
time_t t, t1, t2;
int sec_requested, sec_adjustment;
@dots{}
t1 = t + sec_requested;
t2 = t1 + sec_adjustment;
if (((t1 < t) != (sec_requested < 0))
    | ((t2 < t1) != (sec_adjustment < 0)))
  return -1;
@end example

If your code looks like these examples, it is probably safe even though
it does not strictly conform to the C standard.  This might lead one to
believe that one can generally assume wraparound on overflow, but that
is not always true, as can be seen in the next section.
>>

James.