GNU bug report logs -
#8545
issues with recent doprnt-related changes
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Mon, 25 Apr 2011 05:48:01 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>> If you assign i = INT_MAX + 1, the resulting behavior is undefined.
>
> The result is INT_MIN. We don't try to support any theoretical machine
> where this would not be so.
Those machines used to be theoretical, but they're in common
use now.
I assumed we were talking about type `int', but you did not explicitly
say so. Touché -- but that just means we are talking at cross
purposes. What I said about addition on type int is still valid.
printf ("%d", INT_MAX+1);
will output INT_MIN.
Practical C code can no longer assume that integers
always wrap around when doing integer arithmetic.
I think that is the wrong interpretation of the facts.
long
foo (char *p, int i)
{
return &p[i + 1] - &p[i];
}
On typical hosts where int is 32 bits, and long and char * are
both 64 bits, most compilers optimize that "return" statement
to "return 1;", even when I is INT_MAX and I + 1 therefore
overflows. These compilers are therefore rejecting the notion
that INT_MAX + 1 must always equal INT_MIN.
i+1 is computed as an integer, but then it gets converted to a long.
What happens here seems to be an issue about type conversion combined
with addition -- not addition itself.
These compilers are taking a strange liberty.
Why isn't that a bug?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
This bug report was last modified 4 years and 251 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.