«

<code>
#include <iostream>

int main(void)
{
using namespace std;

int p[100];
int* p1 = p;
int* p11 = p + 2;
int* p2 = p + 12;

ptrdiff_t pd1 = (p2 - p1) * size_t(p11 - p) + (p2-p1) - (p11-p1);
size_t st1 = 30;

cout <<"ptrdiff pd1="<<pd1 <<", size_t st1="<<st1 <<endl;
cout <<"(pd1 < st1)="<<(pd1 < st1) <<endl;
cout <<"(pd1 - st1)="<<(pd1 - st1) <<endl;
cout <<"(st1 - pd1)=" <<(st1 - pd1) <<endl;
cout <<endl;

// for (size_t i=0; i < pd1 - st1 ; ++i) cout <<i << endl;

return 0;
}
</code>

ÀÌ ÇÁ·Î±×·¥ÀÇ ½ÇÇà °á°ú´Â ´ÙÀ½°ú °°½À´Ï´Ù.

<code>
ptrdiff pd1=34, size_t st1=30
(pd1 < st1)=0
(pd1 - st1)=4
(st1 - pd1)=4294967292
</code>

With comparison pd1 is not less than st1; pd1 should be greater than
st1. However the result of the minus operation is reversed.

This is not a makeup code but happen to encounter in coding a program.
The C++ Standard Library container has a size() member function
returning size_t, which is an unsigned type, and the subtraction two
between random access iterators returns ptrdiff_t, which is a signed
type. Using such values, some of the for loops went wrong
unexpectedly.

The compiler I used is as following.

<code>
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c+
+,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-
system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-
threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-
tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
</code>

Thanks,

Ahn, Ki Yung

wrote:
> [redacted]
> ptrdiff pd1=34, size_t st1=30
> (pd1 < st1)=0
> (pd1 - st1)=4
> (st1 - pd1)=4294967292
> </code>
>
> With comparison pd1 is not less than st1; pd1 should be greater than
> st1. However the result of the minus operation is reversed.
>
ptrdiff_t and size_t are unsigned. 30-34 overflows (underflows?)
yielding undefined behavior, however, the most common implementation
would wrap around to 0xFFFFFFFC, or 4294967292.

Again, you cannot rely on that because going outside the range of an
integral type is undefined.

On Wed, 31 Jan 2007 21:37:43 -0800, red floyd <>
wrote in comp.lang.c++:

> wrote:
> > [redacted]
> > ptrdiff pd1=34, size_t st1=30
> > (pd1 < st1)=0
> > (pd1 - st1)=4
> > (st1 - pd1)=4294967292
> > </code>
> >
> > With comparison pd1 is not less than st1; pd1 should be greater than
> > st1. However the result of the minus operation is reversed.
> >
> ptrdiff_t and size_t are unsigned. 30-34 overflows (underflows?)
> yielding undefined behavior, however, the most common implementation
> would wrap around to 0xFFFFFFFC, or 4294967292.

No, ptrdiff_t is and always has been a signed type. When you perform
an arithmetic operation between two different types, in this case
ptrdiff_t which is signed and size_t which is unsigned, there will be
a conversion.

If ptrdiff_t could hold all the values of a size_t, which would
basically mean it would be a wider type than size_t, the size_t value
would be converted to ptrdiff_t and the operation would produce a
signed ptrdiff_t result.

Since on this implementation a ptrdiff_t is the same or of lesser rank
the size_t, it is the ptrdiff_t which is converted to the unsigned
size_t type. The result is well defined.

> Again, you cannot rely on that because going outside the range of an
> integral type is undefined.

Again you are incorrect. What you say is true for signed integer
types, but not true for unsigned integer types. There is no such
thing as overflow or underflow for unsigned types.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

red floyd wrote:
> wrote:
>> [redacted]
>> ptrdiff pd1=34, size_t st1=30
>> (pd1 < st1)=0
>> (pd1 - st1)=4
>> (st1 - pd1)=4294967292
>> </code>
>>
>> With comparison pd1 is not less than st1; pd1 should be greater than
>> st1. However the result of the minus operation is reversed.
>>
> ptrdiff_t and size_t are unsigned.

No, ptrdiff_t is signed. Although, in this case its value gets converted
to an unsigned type.

> 30-34 overflows (underflows?) yielding undefined behavior,

Unsigned integers never overflow.

> however, the most common implementation
> would wrap around to 0xFFFFFFFC, or 4294967292.

Not just "the most common implementation"; unsigned arithmetic wraps in
this manner on *all* implementations.

> Again, you cannot rely on that because going outside the range of an
> integral type is undefined.

No, you *can* rely on this behavior as it is guaranteed by the standard.


--
Clark S. Cox III

Clark S. Cox III wrote:
> red floyd wrote:
>> wrote:
>>> [redacted]
>>> ptrdiff pd1=34, size_t st1=30
>>> (pd1 < st1)=0
>>> (pd1 - st1)=4
>>> (st1 - pd1)=4294967292
>>> </code>
>>>
>>> With comparison pd1 is not less than st1; pd1 should be greater than
>>> st1. However the result of the minus operation is reversed.
>>>
>> ptrdiff_t and size_t are unsigned.
>
> No, ptrdiff_t is signed. Although, in this case its value gets converted
> to an unsigned type.
>
>> 30-34 overflows (underflows?) yielding undefined behavior,
>
> Unsigned integers never overflow.

Really? Would you care to reconcile that with 5/5? "If during the
evaluation of an expression, the result is not mathematically defined or
*not in the range of representable values for its type*, the behavior
is undefined" (emphasis mine).

Combine this with 5/9 "if either operand is unsigned, the other shall be
converted to unsigned".

Yes, ptrdiff_t is signed, but size_t is unsigned. Therefore, as Clark
stated, the ptrdiff_t get converted to an unsigned. Then when we take
30-34, section 5/5 kicks in and we have UB.

red floyd wrote:
> Clark S. Cox III wrote:
>> red floyd wrote:
>>> wrote:
>>>> [redacted]
>>>> ptrdiff pd1=34, size_t st1=30
>>>> (pd1 < st1)=0
>>>> (pd1 - st1)=4
>>>> (st1 - pd1)=4294967292
>>>> </code>
>>>>
>>>> With comparison pd1 is not less than st1; pd1 should be greater than
>>>> st1. However the result of the minus operation is reversed.
>>>>
>>> ptrdiff_t and size_t are unsigned.
>>
>> No, ptrdiff_t is signed. Although, in this case its value gets converted
>> to an unsigned type.
>>
>>> 30-34 overflows (underflows?) yielding undefined behavior,
>>
>> Unsigned integers never overflow.
>
> Really? Would you care to reconcile that with 5/5? "If during the
> evaluation of an expression, the result is not mathematically defined or
> *not in the range of representable values for its type*, the behavior
> is undefined" (emphasis mine).


3.9.1 4:
Unsigned integers, declared unsigned, shall obey the laws of arithmetic
modulo 2 where n is the number of bits in the value representation of
that particular size of integer. 41)

3.9.1 Footnote 41:
This implies that unsigned arithmetic does not overflow because a result
that cannot be represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the largest value
that can be represented by the resulting unsigned integer type.



--
Clark S. Cox III

Clark S. Cox III wrote:
> red floyd wrote:
>> Clark S. Cox III wrote:
>>> red floyd wrote:
>>>> wrote:
>>>>> [redacted]
>>>>> ptrdiff pd1=34, size_t st1=30
>>>>> (pd1 < st1)=0
>>>>> (pd1 - st1)=4
>>>>> (st1 - pd1)=4294967292
>>>>> </code>
>>>>>
>>>>> With comparison pd1 is not less than st1; pd1 should be greater than
>>>>> st1. However the result of the minus operation is reversed.
>>>>>
>>>> ptrdiff_t and size_t are unsigned.
>>> No, ptrdiff_t is signed. Although, in this case its value gets converted
>>> to an unsigned type.
>>>
>>>> 30-34 overflows (underflows?) yielding undefined behavior,
>>> Unsigned integers never overflow.
>> Really? Would you care to reconcile that with 5/5? "If during the
>> evaluation of an expression, the result is not mathematically defined or
>> *not in the range of representable values for its type*, the behavior
>> is undefined" (emphasis mine).
>
>
> 3.9.1 4:
> Unsigned integers, declared unsigned, shall obey the laws of arithmetic
> modulo 2 where n is the number of bits in the value representation of
> that particular size of integer. 41)
>
> 3.9.1 Footnote 41:
> This implies that unsigned arithmetic does not overflow because a result
> that cannot be represented by the resulting unsigned integer type is
> reduced modulo the number that is one greater than the largest value
> that can be represented by the resulting unsigned integer type.
>

That's *OVERFLOW*. What about *UNDERFLOW*?

red floyd wrote:
> Clark S. Cox III wrote:
>> red floyd wrote:
>>> Clark S. Cox III wrote:
>>>> red floyd wrote:
>>>>> wrote:
>>>>>> [redacted]
>>>>>> ptrdiff pd1=34, size_t st1=30
>>>>>> (pd1 < st1)=0
>>>>>> (pd1 - st1)=4
>>>>>> (st1 - pd1)=4294967292
>>>>>> </code>
>>>>>>
>>>>>> With comparison pd1 is not less than st1; pd1 should be greater than
>>>>>> st1. However the result of the minus operation is reversed.
>>>>>>
>>>>> ptrdiff_t and size_t are unsigned.
>>>> No, ptrdiff_t is signed. Although, in this case its value gets
>>>> converted
>>>> to an unsigned type.
>>>>
>>>>> 30-34 overflows (underflows?) yielding undefined behavior,
>>>> Unsigned integers never overflow.
>>> Really? Would you care to reconcile that with 5/5? "If during the
>>> evaluation of an expression, the result is not mathematically defined or
>>> *not in the range of representable values for its type*, the behavior
>>> is undefined" (emphasis mine).
>>
>>
>> 3.9.1 4:
>> Unsigned integers, declared unsigned, shall obey the laws of arithmetic
>> modulo 2 where n is the number of bits in the value representation of
>> that particular size of integer. 41)
>>
>> 3.9.1 Footnote 41:
>> This implies that unsigned arithmetic does not overflow because a result
>> that cannot be represented by the resulting unsigned integer type is
>> reduced modulo the number that is one greater than the largest value
>> that can be represented by the resulting unsigned integer type.
>>
>
> That's *OVERFLOW*. What about *UNDERFLOW*?

The term underflow is only really relevant to floating point types, as
it deals with a result whose magnitude is too small to represent (i.e.
the value is too close to zero). What you're talking about is still
called overflow.


--
Clark S. Cox III

red floyd wrote:

> Clark S. Cox III wrote:
>> red floyd wrote:
>>> Clark S. Cox III wrote:
>>>> red floyd wrote:
>>>>> wrote:
>>>>>> [redacted]
>>>>>> ptrdiff pd1=34, size_t st1=30
>>>>>> (pd1 < st1)=0
>>>>>> (pd1 - st1)=4
>>>>>> (st1 - pd1)=4294967292
>>>>>> </code>
>>>>>>
>>>>>> With comparison pd1 is not less than st1; pd1 should be greater than
>>>>>> st1. However the result of the minus operation is reversed.
>>>>>>
>>>>> ptrdiff_t and size_t are unsigned.
>>>> No, ptrdiff_t is signed. Although, in this case its value gets
>>>> converted
>>>> to an unsigned type.
>>>>
>>>>> 30-34 overflows (underflows?) yielding undefined behavior,
>>>> Unsigned integers never overflow.
>>> Really? Would you care to reconcile that with 5/5? "If during the
>>> evaluation of an expression, the result is not mathematically defined or
>>> *not in the range of representable values for its type*, the behavior
>>> is undefined" (emphasis mine).
>>
>>
>> 3.9.1 4:
>> Unsigned integers, declared unsigned, shall obey the laws of arithmetic
>> modulo 2 where n is the number of bits in the value representation of
>> that particular size of integer. 41)
>>
>> 3.9.1 Footnote 41:
>> This implies that unsigned arithmetic does not overflow because a result
>> that cannot be represented by the resulting unsigned integer type is
>> reduced modulo the number that is one greater than the largest value
>> that can be represented by the resulting unsigned integer type.
>>
>
> That's *OVERFLOW*. What about *UNDERFLOW*?

Don't focus on the footnote. The normative clause covers it all because
arithmetic mod 2^n does not care either way. All arithmetic operations with
the exception of division by 0 are well-defined for unsigned interger types
by [3.9.1.4]. (That's why I like them much better than those signed types
that make virtually no guarantees whatsoever.)


Best

Kai-Uwe Bux

Kai-Uwe Bux wrote:

>>>>>> 30-34 overflows (underflows?) yielding undefined behavior,
>>>>> Unsigned integers never overflow.
>>>> Really? Would you care to reconcile that with 5/5? "If during the
>>>> evaluation of an expression, the result is not mathematically defined or
>>>> *not in the range of representable values for its type*, the behavior
>>>> is undefined" (emphasis mine).
>>>
>>> 3.9.1 4:
>>> Unsigned integers, declared unsigned, shall obey the laws of arithmetic
>>> modulo 2 where n is the number of bits in the value representation of
>>> that particular size of integer. 41)
>>>
>>> 3.9.1 Footnote 41:
>>> This implies that unsigned arithmetic does not overflow because a result
>>> that cannot be represented by the resulting unsigned integer type is
>>> reduced modulo the number that is one greater than the largest value
>>> that can be represented by the resulting unsigned integer type.
>>>
>> That's *OVERFLOW*. What about *UNDERFLOW*?
>
> Don't focus on the footnote. The normative clause covers it all because
> arithmetic mod 2^n does not care either way. All arithmetic operations with
> the exception of division by 0 are well-defined for unsigned interger types
> by [3.9.1.4]. (That's why I like them much better than those signed types
> that make virtually no guarantees whatsoever.)

OK. I stand corrected. Sorry about being such a pain.