Strange result from ptrdiff_t and size_t

Discussion in 'C++' started by kyagrd@gmail.com, Feb 1, 2007.

  1. Guest

    <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
    , Feb 1, 2007
    #1
    1. Advertising

  2. red floyd Guest

    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.
    red floyd, Feb 1, 2007
    #2
    1. Advertising

  3. Jack Klein Guest

    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/~ajo/docs/FAQ-acllc.html
    Jack Klein, Feb 1, 2007
    #3
  4. 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, Feb 1, 2007
    #4
  5. red floyd Guest

    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, Feb 1, 2007
    #5
  6. 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, Feb 1, 2007
    #6
  7. red floyd Guest

    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, Feb 1, 2007
    #7
  8. 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
    Clark S. Cox III, Feb 1, 2007
    #8
  9. Kai-Uwe Bux Guest

    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, Feb 1, 2007
    #9
  10. red floyd Guest

    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.
    red floyd, Feb 2, 2007
    #10
  11. red floyd Guest

    Kai-Uwe Bux wrote:

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


    You know, there should be a note in 5/5 to refer to 3.9.1.4.
    red floyd, Feb 2, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Plauger, size_t and ptrdiff_t

    , Feb 17, 2006, in forum: C Programming
    Replies:
    26
    Views:
    687
    Dave Thompson
    Mar 3, 2006
  2. Replies:
    6
    Views:
    6,354
    Greg Comeau
    Oct 19, 2005
  3. Replies:
    9
    Views:
    1,276
    Howard Hinnant
    Oct 25, 2005
  4. James Harris

    size_t, ssize_t and ptrdiff_t

    James Harris, Oct 12, 2013, in forum: C Programming
    Replies:
    56
    Views:
    644
    Albert van der Horst
    Oct 25, 2013
  5. zloy tapok

    size_t and ptrdiff_t

    zloy tapok, Feb 27, 2014, in forum: C Programming
    Replies:
    1
    Views:
    74
    Eric Sosman
    Feb 27, 2014
Loading...

Share This Page