[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8545: issues with recent doprnt-related changes
From: |
Paul Eggert |
Subject: |
bug#8545: issues with recent doprnt-related changes |
Date: |
Sat, 30 Apr 2011 22:41:38 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 |
On 04/30/11 14:03, Richard Stallman wrote:
> long
> foo (char *p, int i)
> {
> return &p[i + 1] - &p[i];
> }
> ...
> i+1 is computed as an integer, but then it gets converted to a long.
Unfortunately that doesn't explain FOO's behavior.
If i+1 is computed as an int and if wraparound is required, then
when i is INT_MAX, i+1 must be INT_MIN. (FOO does not convert
i+1 to long; but even if it did, INT_MIN's value would be unchanged by
that conversion.) If p is pointing into a large array, &p[INT_MIN]
and &p[INT_MAX] can both be valid addresses, and in that case
foo (p, INT_MAX) would have to yield -2**32 + 1 on a typical 64-bit host
where signed integer arithmetic wrapped around.
But in my experience no compiler does it that way. FOO always returns 1.
> What happens here seems to be an issue about type conversion combined
> with addition -- not addition itself.
I'm afraid not. First, FOO doesn't have any type conversions.
If I is an int, A[I] doesn't convert I to any other type; it
simply uses I's value without conversion.
Second, it's easy to construct an example that involves only "int":
int
bar (int i)
{
return i < i + 1;
}
With many compilers, BAR always returns 1, even when i == INT_MAX.
> These compilers are taking a strange liberty.
> Why isn't that a bug?
Well, for starters, most programmers *expect* FOO to return 1,
and similarly for BAR. Why would a programmer file a bug report
when the program is behaving as expected?
> printf ("%d", INT_MAX+1);
> will output INT_MIN.
That's true for all systems I have ready access to, yes. And I
expect there are other cases where int arithmetic wraps around
reliably. But there are many practical cases where it doesn't.
We cannot simply advise programmers to assume that adding 1
to INT_MAX always results in INT_MIN, as that assumption is
often incorrect nowadays.
bug#8545: issues with recent doprnt-related changes, Paul Eggert, 2011/05/04
- bug#8545: issues with recent doprnt-related changes, Eli Zaretskii, 2011/05/04
- bug#8545: issues with recent doprnt-related changes, Paul Eggert, 2011/05/04
- bug#8545: issues with recent doprnt-related changes, Eli Zaretskii, 2011/05/05
- bug#8545: issues with recent doprnt-related changes, Stefan Monnier, 2011/05/06
- bug#8545: issues with recent doprnt-related changes, Paul Eggert, 2011/05/06
- bug#8545: issues with recent doprnt-related changes, Eli Zaretskii, 2011/05/06