Pointer arithmetic questions

Discussion in 'C++' started by MOvetsky@gmail.com, Apr 26, 2005.

  1. Guest

    Is the following code ISO C++ standard compliant?
    If yes, is it guaranteed that it will not crash on compliant platforms?
    If yes, will it print "Pointers are equal" on any compliant platform?
    Will answers be the same if p points to local memory or string literal?


    char *p = new char[10];
    char *p1 = p-1;
    p1 = p1 + 1;

    if(p1 == p)
    {
    cout << "Pointers are equal" << endl;
    }

    Thank you,

    Michael
     
    , Apr 26, 2005
    #1
    1. Advertising

  2. Alvin Guest

    wrote:

    > Is the following code ISO C++ standard compliant?
    > If yes, is it guaranteed that it will not crash on compliant platforms?
    > If yes, will it print "Pointers are equal" on any compliant platform?
    > Will answers be the same if p points to local memory or string literal?
    >
    >
    > char *p = new char[10];
    > char *p1 = p-1;
    > p1 = p1 + 1;
    >
    > if(p1 == p)
    > {
    > cout << "Pointers are equal" << endl;
    > }
    >
    > Thank you,
    >
    > Michael


    I would say this is standard compliant (without looking it up). That said,
    using p1 before incrementing is undefined (obviously).

    Someone correct me if I'm wrong but all that has been done is p1 is set to
    1*sizeof(char) before p. I say 1*sizeof(char) because it depends on the
    size of a char on the system. For most systems, sizeof(char) is 1; so p1 is
    intialised to 1 byte before p. If you use int instead of char, then it
    would be 4 bytes (on my 32bit machine) before p.

    But you don't need to be concerned with the particulars really, That's the
    beauty of pointer arithmetic!

    --
    Alvin
     
    Alvin, Apr 26, 2005
    #2
    1. Advertising

  3. Pete Becker Guest

    Alvin wrote:
    >
    > I would say this is standard compliant (without looking it up).


    Then you'd better look it up. <g> The rule for pointer arithmetic is
    that you can move around within an array or to one position past the
    end. You can't go in front of the beginning.

    >
    > For most systems, sizeof(char) is 1;
    >


    sizeof(char) is defined to be 1.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 26, 2005
    #3
  4. Alvin Guest

    Pete Becker wrote:

    > Alvin wrote:
    >>
    >> I would say this is standard compliant (without looking it up).

    >
    > Then you'd better look it up. <g> The rule for pointer arithmetic is
    > that you can move around within an array or to one position past the
    > end. You can't go in front of the beginning.
    >
    >>
    >> For most systems, sizeof(char) is 1;
    >>

    >
    > sizeof(char) is defined to be 1.
    >


    I guess I didn't make myself clear. By standard compliant I was trying to
    say p1 = p-1 was compliant. I didn't intend on saying the result was
    compliant.

    I guess what you are saying is the act of going in front of the array is
    undefined.

    --
    Alvin
     
    Alvin, Apr 26, 2005
    #4
  5. wrote:

    > Is the following code


    > cat main.cc

    #include <iostream>

    int main(int argc, char* argv[]) {
    char* p = new char[10];
    char* p1 = p - 1;
    p1 = p1 + 1;

    if (p1 == p) {
    std::cout << "Pointers are equal." << std::endl;
    }

    return 0;
    }

    > g++ -Wall -ansi -pedantic -o main main.cc
    > ./main

    Pointers are equal.

    > ISO C++ standard compliant?


    No.

    > If yes, is it guaranteed that it will not crash on compliant platforms?


    Who would guarantee that compliant code will not crash?

    > If yes, will it print "Pointers are equal." on any compliant platform?


    It *will* print "Pointers are equal." on *every* compliant platform
    even though the code itself is non-compliant.
    Nobody guarantees that non-compliant code *will* crash either.

    > Will answers be the same if p points to local memory or string literal?


    > cat main.cc

    #include <iostream>

    int main(int argc, char* argv[]) {
    const
    char* p = "Pointers are equal.";
    char* p1 = p - 1;
    p1 = p1 + 1;

    if (p1 == p) {
    std::cout << "Pointers are equal." << std::endl;
    }

    return 0;
    }

    > g++ -Wall -ansi -pedantic -o main main.cc

    main.cc: In function `int main(int, char**)':
    main.cc:6: error: \
    invalid conversion from `const char*' to `char*'

    Why couldn't you perform this simple experiment yourself?
    Your compiler will answer most of these questions.
    Next time, please show us the results from your experiments
    and convince us that you are *not* just another lazy programmer.
     
    E. Robert Tisdale, Apr 26, 2005
    #5
  6. <> wrote in message
    news:...
    > Is the following code ISO C++ standard compliant?


    It's not compliant, but I'd honestly be amazed if you could find me a
    compiler/runtime environment combination that failed to run it and give you the
    output you expect.

    - JFA1
     
    James Aguilar, Apr 26, 2005
    #6
  7. BigBrian Guest

    Pete Becker wrote:
    > Then you'd better look it up. <g> The rule for pointer arithmetic is
    > that you can move around within an array or to one position past the
    > end. You can't go in front of the beginning.
    >


    Your comment seems to imply that there's something checking the end
    points of the array. There is not. You *can* go in front. You can
    even do pointer arithmetic on a pointer that's not even pointing to an
    array. It compiles, ( but that doesn't mean it doesn't produce
    undefined behavior ).

    -Brian
     
    BigBrian, Apr 26, 2005
    #7
  8. "James Aguilar" <> wrote in message
    news:d4m6c0$pc2$...
    > <> wrote in message


    > It's not compliant, but I'd honestly be amazed if you could find me a
    > compiler/runtime environment combination that failed to run it and give
    > you the output you expect.


    There was an implementation a number of years ago that would terminate such
    programs with a diagnostic message. However, I don't think that the company
    that produced that implementation is still in business, nor do I know what
    other implementations might behave the same way.
     
    Andrew Koenig, Apr 26, 2005
    #8
  9. Guest

    E. Robert Tisdale wrote:

    > Why couldn't you perform this simple experiment yourself?


    Actually I checked it on Visual C++ 6.0 and gcc on Solaris and Linux
    and got the expected results.
    However, the point of my questions was to figure out if it was a safe
    practice to use it on arbitrary platform and what ISO standard said
    about it.

    So from what I hear it is a bad idea to use the code like this for
    multi platform development (even though the probability to get in
    trouble is low).

    Michael
     
    , Apr 26, 2005
    #9
  10. Pete Becker Guest

    BigBrian wrote:

    >
    > Your comment seems to imply that there's something checking the end
    > points of the array.


    Nope.

    > There is not. You *can* go in front. You can
    > even do pointer arithmetic on a pointer that's not even pointing to an
    > array. It compiles,


    Not necessarily. The behavior is undefined, and that means you cannot
    count on anything in particular. There is nothing in the language
    definition that requires this code to compile. Don't use compilers to
    test code conformance.

    By the way, when most people say "you can't to that" there's an implied
    "in conforming code."

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 26, 2005
    #10
  11. Pete Becker Guest

    James Aguilar wrote:

    >
    > It's not compliant, but I'd honestly be amazed if you could find me a
    > compiler/runtime environment combination that failed to run it and give you the
    > output you expect.
    >


    Win16 with a memory manager that returns blocks in distinct segments;
    you can't address below 0 within a segment (it wraps around, and faults
    because it's out of range).

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 26, 2005
    #11
  12. Uenal Mutlu Guest

    "Pete Becker" wrote
    > BigBrian wrote:
    >
    > >
    > > Your comment seems to imply that there's something checking the end
    > > points of the array.

    >
    > Nope.
    >
    > > There is not. You *can* go in front. You can
    > > even do pointer arithmetic on a pointer that's not even pointing to an
    > > array. It compiles,

    >
    > Not necessarily. The behavior is undefined, and that means you cannot
    > count on anything in particular. There is nothing in the language
    > definition that requires this code to compile. Don't use compilers to
    > test code conformance.
    >
    > By the way, when most people say "you can't to that" there's an implied
    > "in conforming code."


    Sorry, I don't get it. Why should it not compile? A ptr is just a ptr, it can
    point anywhere.
     
    Uenal Mutlu, Apr 27, 2005
    #12
  13. Old Wolf Guest

    Alvin wrote:
    > Pete Becker wrote:
    > > Alvin wrote:
    > >>
    > >> I would say this is standard compliant (without looking it up).

    > >
    > > Then you'd better look it up. <g> The rule for pointer
    > > arithmetic is that you can move around within an array
    > > or to one position past the end. You can't go in front
    > > of the beginning.

    >
    > I guess I didn't make myself clear. By standard compliant I was
    > trying to say p1 = p-1 was compliant. I didn't intend on saying
    > the result was compliant.


    The expression (p-1) causes undefined behaviour.
     
    Old Wolf, Apr 27, 2005
    #13
  14. BigBrian Guest

    > By the way, when most people say "you can't to that" there's an
    implied
    > "in conforming code."


    I'll try to remember that your messages have an implied "in conforming
    code", however, it may be easier if you just include it so there's no
    confusion.

    -Brian
     
    BigBrian, Apr 27, 2005
    #14
  15. Guest

    I can't believe that
    char *p1 = p-1; //(1)
    p1 = p1 + 1; //(2)
    causes undefined behavior as noted by Old Wolf.

    I would really like to know why is it so, please someone explain why?

    As far as I'm concerned the code is valid if there's substraction and
    addition for pointers defined (which is defined). In short
    line 1: p1 = address_of(p) - 1*sizeof(*p);
    line 2 p1 = address_of(p1) + 1*sizeof(*p1);
    how is that phisically may trigger any sort of problem unless generated
    code tests result of every pointer operation? Basicly on the first line
    p1 is assigned address of the char that precedes (*p) and even if it's
    0 why then p1 = 0 should be any different from p1 = p-1???
    Even if it wraps in win16 as noted by Pete Becker I still don't
    understand what causes segfault?!? The behavior would be surely
    undefined if the OP tried to access the char pointed by p1 before line2
    was executed. Basicly from machine code it's absolutely valid, but
    probably c++ forbids such arithmetics (why?!?)... please explaint
    better someone who knows!

    Thanks
     
    , Apr 27, 2005
    #15
  16. Ron Natalie Guest

    wrote:

    > I would really like to know why is it so, please someone explain why?


    You've been told why. Please read the messages.
    >
    > As far as I'm concerned the code is valid if there's substraction and
    > addition for pointers defined (which is defined).


    No, it's only defined over the space of a single object. The issue is
    machines where there are segments or banks mean a pointer isn't just a
    byte offset from the beginning of address space. There's no
    requirement that the thing graciously roll negative off the beginning
    of a segment. Because of decades of bad programming assumptions, going
    off by one the other way was deemed to be acceptible.

    While C++ puts no bounds on the errors that might come from exploiting
    undefined behavior, a very real one is that
    (ptr - 1) + 1
    doesn't put you back at the original ptr value.
     
    Ron Natalie, Apr 27, 2005
    #16
  17. Old Wolf Guest

    Uenal Mutlu wrote:
    > "Pete Becker" wrote
    >> BigBrian wrote:
    >>>
    >>> Your comment seems to imply that there's something checking the
    >>> end points of the array.

    >>
    >> Nope.
    >>
    >>> There is not. You *can* go in front. You can
    >>> even do pointer arithmetic on a pointer that's not even pointing
    >>> to an array. It compiles,

    >>
    >> Not necessarily. The behavior is undefined, and that means you
    >> cannot count on anything in particular. There is nothing in the
    >> language definition that requires this code to compile. Don't
    >> use compilers to test code conformance.

    >
    > Sorry, I don't get it. Why should it not compile? A ptr is just
    > a ptr, it can point anywhere.


    Wrong. A pointer must either be null, indeterminate, or
    point to part of an object that exists (or point to a function).

    You might be used to some systems (eg. Windows 95) where a pointer
    can point anywhere, but that does not apply to all possible systems.

    One such example: a CPU could generate a hardware exception
    when one of its address registers is loaded with an invalid
    address, or an address not owned by the current thread.
    So when you go (p - 1) you are trying to point to a different
    thread's memory, and the CPU immediately kills the thread for
    an access violation.

    Another good example was given by Pete Becker: why should a
    system have to do anything sensible if you subtract 1 from
    an address of 0 ? What is (1000:0) - 1? (ie. segment 1000 offset 0)
     
    Old Wolf, Apr 27, 2005
    #17
  18. wrote:
    > I can't believe that
    > char *p1 = p-1; //(1)
    > p1 = p1 + 1; //(2)
    > causes undefined behavior as noted by Old Wolf.
    >
    > I would really like to know why is it so, please someone explain why?
    >
    > As far as I'm concerned the code is valid if there's substraction and
    > addition for pointers defined (which is defined). In short
    > line 1: p1 = address_of(p) - 1*sizeof(*p);
    > line 2 p1 = address_of(p1) + 1*sizeof(*p1);
    > how is that phisically may trigger any sort of problem unless generated
    > code tests result of every pointer operation? Basicly on the first line
    > p1 is assigned address of the char that precedes (*p) and even if it's
    > 0 why then p1 = 0 should be any different from p1 = p-1???
    > Even if it wraps in win16 as noted by Pete Becker I still don't
    > understand what causes segfault?!? The behavior would be surely
    > undefined if the OP tried to access the char pointed by p1 before line2
    > was executed. Basicly from machine code it's absolutely valid, but
    > probably c++ forbids such arithmetics (why?!?)... please explaint
    > better someone who knows!
    >
    > Thanks
    >


    Read ISO9899:1999 section 6.5.6 paragraph 8:

    <quote>
    When an expression that has integer type is added to or subtracted from
    a pointer, the
    result has the type of the pointer operand. If the pointer operand
    points to an element of
    an array object, and the array is large enough, the result points to an
    element offset from
    the original element such that the difference of the subscripts of the
    resulting and original
    array elements equals the integer expression. In other words, if the
    expression P points to
    the i-th element of an array object, the expressions (P)+N
    (equivalently, N+(P)) and
    (P)-N (where N has the value n) point to, respectively, the i+n-th and
    i−n-th elements of
    the array object, provided they exist. Moreover, if the expression P
    points to the last
    element of an array object, the expression (P)+1 points one past the
    last element of the
    array object, and if the expression Q points one past the last element
    of an array object,
    the expression (Q)-1 points to the last element of the array object. If
    both the pointer
    operand and the result point to elements of the same array object, or
    one past the last
    element of the array object, the evaluation shall not produce an
    overflow; otherwise, the
    behavior is undefined. If the result points one past the last element of
    the array object, it
    shall not be used as the operand of a unary * operator that is evaluated.
    </quote>

    especially the last two sentences...

    Tom
     
    Thomas Maier-Komor, Apr 27, 2005
    #18
  19. Thomas Maier-Komor wrote:
    > wrote:
    >
    >> I can't believe that
    >> char *p1 = p-1; //(1)
    >> p1 = p1 + 1; //(2)
    >> causes undefined behavior as noted by Old Wolf.
    >>
    >> I would really like to know why is it so, please someone explain why?
    >>
    >> As far as I'm concerned the code is valid if there's substraction and
    >> addition for pointers defined (which is defined). In short
    >> line 1: p1 = address_of(p) - 1*sizeof(*p);
    >> line 2 p1 = address_of(p1) + 1*sizeof(*p1);
    >> how is that phisically may trigger any sort of problem unless generated
    >> code tests result of every pointer operation? Basicly on the first line
    >> p1 is assigned address of the char that precedes (*p) and even if it's
    >> 0 why then p1 = 0 should be any different from p1 = p-1???
    >> Even if it wraps in win16 as noted by Pete Becker I still don't
    >> understand what causes segfault?!? The behavior would be surely
    >> undefined if the OP tried to access the char pointed by p1 before line2
    >> was executed. Basicly from machine code it's absolutely valid, but
    >> probably c++ forbids such arithmetics (why?!?)... please explaint
    >> better someone who knows!
    >>
    >> Thanks
    >>

    >
    > Read ISO9899:1999 section 6.5.6 paragraph 8:
    >
    > <quote>
    > When an expression that has integer type is added to or subtracted from
    > a pointer, the
    > result has the type of the pointer operand. If the pointer operand
    > points to an element of
    > an array object, and the array is large enough, the result points to an
    > element offset from
    > the original element such that the difference of the subscripts of the
    > resulting and original
    > array elements equals the integer expression. In other words, if the
    > expression P points to
    > the i-th element of an array object, the expressions (P)+N
    > (equivalently, N+(P)) and
    > (P)-N (where N has the value n) point to, respectively, the i+n-th and
    > i−n-th elements of
    > the array object, provided they exist. Moreover, if the expression P
    > points to the last
    > element of an array object, the expression (P)+1 points one past the
    > last element of the
    > array object, and if the expression Q points one past the last element
    > of an array object,
    > the expression (Q)-1 points to the last element of the array object. If
    > both the pointer
    > operand and the result point to elements of the same array object, or
    > one past the last
    > element of the array object, the evaluation shall not produce an
    > overflow; otherwise, the
    > behavior is undefined. If the result points one past the last element of
    > the array object, it
    > shall not be used as the operand of a unary * operator that is evaluated.
    > </quote>
    >
    > especially the last two sentences...
    >
    > Tom


    sorry that was the wrong standard...
    but in ISO14882 section 5.7 paragraph 5 the text is almost the same:

    <quote>
    When an expression that has integral type is added to or subtracted from
    a pointer, the result has the type of
    the pointer operand. If the pointer operand points to an element of an
    array object, and the array is large
    enough, the result points to an element offset from the original element
    such that the difference of the subscripts
    of the resulting and original array elements equals the integral
    expression. In other words, if the
    expression P points to the i-th element of an array object, the
    expressions (P)+N (equivalently, N+(P))
    and (P)-N (where N has the value n) point to, respectively, the i+n-th
    and i–n-th elements of the array
    object, provided they exist. Moreover, if the expression P points to the
    last element of an array object, the
    expression (P)+1 points one past the last element of the array object,
    and if the expression Q points one
    past the last element of an array object, the expression (Q)-1 points to
    the last element of the array object.
    If both the pointer operand and the result point to elements of the same
    array object, or one past the last element
    of the array object, the evaluation shall not produce an overflow;
    otherwise, the behavior is undefined.
    </quote>

    Tom
     
    Thomas Maier-Komor, Apr 27, 2005
    #19
  20. Guest

    in other words according to the standard
    unsigned char* some_random_address = 0xabc12345;
    has undefined behavior becase it doesn't point to an array element or
    one past the array... It simply means that I cannot have a pointer to
    an arbitrary element in memory (even if no such area addressable etc
    etc, but I just cannot have an arbitraty address)?, it seems to be very
    strange if not ridiculous. If programming in asembler there's no
    difference wether a pointer points to first, last, arbitrary memory, 0,
    0-1 ... all comes up when you access this regions by the pointer.
    It's very surprising for me to know about that, thanks for the info
    Tom.

    ps. anyways, I can't believe that the code of original poster could
    have any other behavior than printing that the pointers are equal. Even
    it's win16 or whatever as long as the generated code doesn't checks the
    result of every pointer operation not to point to arbitrary memory then
    it should not have any problems. Maybe in C it's ok to do so? :)
     
    , Apr 27, 2005
    #20
    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. a

    pointer arithmetic

    a, Sep 11, 2003, in forum: C++
    Replies:
    6
    Views:
    524
  2. Marc Schellens

    Iterator/pointer arithmetic

    Marc Schellens, Dec 5, 2003, in forum: C++
    Replies:
    15
    Views:
    850
    tom_usenet
    Dec 8, 2003
  3. dan

    Pointer arithmetic

    dan, Jan 6, 2004, in forum: C++
    Replies:
    1
    Views:
    364
    Jeff Schwab
    Jan 6, 2004
  4. ceo
    Replies:
    8
    Views:
    359
    Pete Becker
    Mar 10, 2005
  5. joshc
    Replies:
    5
    Views:
    559
    Keith Thompson
    Mar 31, 2005
Loading...

Share This Page