Pointers and Sequence Point

Discussion in 'C Programming' started by arnuld, May 2, 2011.

  1. arnuld

    arnuld Guest

    I have this program which is causing confusion to me. I am told that last
    printf() of main() will always print "Second", not "First". I think line:

    x = myAlloc(x);

    is UB. My colleague is disagreeing on this while I was saying that its UB
    because there is no sequence point here. It is just like using this line:

    i = i++;

    But he says that sequence point will not affect the pointers and hence
    this is perfectly valid ANSI C program. I am confused on this:



    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    enum { SIZE_LIMIT = 10 };

    char* myAlloc(char* c);

    int main(void)
    {
    char* x = malloc(SIZE_LIMIT * sizeof *x);
    if(NULL == x)
    {
    printf("Out of Memory\n");
    return EXIT_FAILURE;
    }

    strcpy(x, "First");
    printf("x = %s\n", x);
    x = myAlloc(x);
    printf("x = %s\n", x);

    return 0;
    }


    char* myAlloc(char* c)
    {
    c = malloc(SIZE_LIMIT * sizeof *c);
    if(NULL == c)
    {
    printf("Out of Memory\n");
    return NULL;
    }
    else
    {
    strcpy(c, "Second");
    }

    return c;
    }


    ================= OUTPUT ====================
    [arnuld@dune programs]$ gcc -ansi -pedantic -Wall -Wextra ptrtest.c
    [arnuld@dune programs]$ ./a.out
    x = First
    x = Second
    [arnuld@dune programs]$





    --
    www.lispmachine.wordpress.com
    find my email-ID @above blog
     
    arnuld, May 2, 2011
    #1
    1. Advertising

  2. arnuld

    James Kuyper Guest

    On 05/02/2011 07:38 AM, arnuld wrote:
    > I have this program which is causing confusion to me. I am told that last
    > printf() of main() will always print "Second", not "First". I think line:
    >
    > x = myAlloc(x);
    >
    > is UB. My colleague is disagreeing on this while I was saying that its UB
    > because there is no sequence point here. It is just like using this line:
    >
    > i = i++;


    No, it's not. 6.5p2 contains two separate "shalls" that apply between
    consecutive sequence points. "i=i++" violates the first one, against
    modifying the value of an object twice. Your example modifies the value
    of x only once. I presume, therefore, that you're actually worried about
    the second one, against reading the value for any purpose other than to
    determine what the new value is.

    > But he says that sequence point will not affect the pointers and hence
    > this is perfectly valid ANSI C program. I am confused on this:


    There is no special exemption of pointers from the rules involving
    multiple modifications with no intervening sequence points. "x=x++"
    would be just as thoroughly undefined as "i = i++". It's just that
    there's a whole lot more relevant sequence points involved in the
    evaluation of "x = myAlloc(x)" than you're taking into consideration.

    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <string.h>
    >
    > enum { SIZE_LIMIT = 10 };
    >
    > char* myAlloc(char* c);
    >
    > int main(void)
    > {
    > char* x = malloc(SIZE_LIMIT * sizeof *x);
    > if(NULL == x)
    > {
    > printf("Out of Memory\n");
    > return EXIT_FAILURE;
    > }
    >
    > strcpy(x, "First");
    > printf("x = %s\n", x);
    > x = myAlloc(x);


    There's a sequence point separating evaluation of 'x' as an argument to
    myAlloc() from the call to myAlloc() (6.5.2.2p10).

    > printf("x = %s\n", x);
    >
    > return 0;
    > }
    >
    >
    > char* myAlloc(char* c)
    > {
    > c = malloc(SIZE_LIMIT * sizeof *c);


    There's a sequence point separating the multiplication from the call to
    malloc(), another just before malloc() returns (7.1.4p3), a third at the
    end of the full expression (6.8p4).


    > if(NULL == c)


    There's a sequence point at the end of the full expression.

    > {
    > printf("Out of Memory\n");
    > return NULL;
    > }
    > else
    > {
    > strcpy(c, "Second");


    There's a sequence point separating the evaluation of the arguments from
    the call to strcpy(), a second just before strcpy() returns, and a third
    at the end of the full expression.

    > }
    >
    > return c;


    There's a sequence point at the end of the full expression.

    > }


    I count a total of 9 sequence points separating the reading of the value
    of x from its modification. One is all that's needed to avoid violating
    6.5p2.

    --
    James Kuyper
     
    James Kuyper, May 2, 2011
    #2
    1. Advertising

  3. On 5/2/2011 7:38 AM, arnuld wrote:
    > I have this program which is causing confusion to me. I am told that last
    > printf() of main() will always print "Second", not "First". I think line:
    >
    > x = myAlloc(x);


    While it is possible to write evil code in which myAlloc could modify x,
    in C myAlloc receives a copy of the value of x and has no clue where x
    is or how to modify it. There are not two or more instances of
    modifying x between sequence points.

    > is UB. My colleague is disagreeing on this while I was saying that its UB
    > because there is no sequence point here. It is just like using this line:
    >
    > i = i++;


    Now there _are_ two instances of modifying i between sequence points.

    Do you see the difference?

    > But he says that sequence point will not affect the pointers


    "pointers" are not relevant.

    > and hence
    > this is perfectly valid ANSI C program. I am confused on this:


    Your program has other problems, but none related to the question you
    raised.
     
    Martin Ambuhl, May 2, 2011
    #3
  4. arnuld

    Chad Guest

    On May 2, 6:58 am, Martin Ambuhl <> wrote:
    > On 5/2/2011 7:38 AM, arnuld wrote:
    >
    > > I have this program which is causing confusion to me. I am told that last
    > > printf() of main() will always print "Second", not "First". I think line:

    >
    > >   x = myAlloc(x);

    >
    > While it is possible to write evil code in which myAlloc could modify x,
    > in C myAlloc receives a copy of the value of x and has no clue where x
    > is or how to modify it.  There are not two or more instances of
    > modifying x between sequence points.
    >


    What is the scope of 'x' in myAlloc(x)? Is confined to myAlloc()?

    Chad
     
    Chad, May 2, 2011
    #4
  5. arnuld

    John Bode Guest

    On May 2, 6:38 am, arnuld <> wrote:
    > I have this program which is causing confusion to me. I am told that last
    > printf() of main() will always print "Second", not "First". I think line:
    >
    >  x = myAlloc(x);
    >
    > is UB.


    *Only* if myAlloc is a macro that expands to something like "x++" or
    similar. If myAlloc is a function call, then that's not UB at all for
    two reasons:

    1. Evaluating "myAlloc(x)" does not modify "x": even if "myAlloc"
    writes to its argument, that argument is a physically distinct object
    in memory from "x";

    2. There is *at least one* intervening sequence point before the
    assignment to "x" between the time the function argument is evaluated
    and the function itself is called, not to mention any sequence points
    in the function itself.

    > My colleague is disagreeing on this while I was saying that its UB
    > because there is no sequence point here. It is just like using this line:
    >
    >  i = i++;
    >


    Your colleague is correct.

    > But he says that sequence point will not affect the pointers


    But for the wrong reason, unless he misspoke or you misheard.
     
    John Bode, May 2, 2011
    #5
  6. arnuld

    Angel Guest

    On 2011-05-02, Chad <> wrote:
    > On May 2, 6:58?am, Martin Ambuhl <> wrote:
    >> On 5/2/2011 7:38 AM, arnuld wrote:
    >>
    >> > I have this program which is causing confusion to me. I am told that last
    >> > printf() of main() will always print "Second", not "First". I think line:

    >>
    >> > ? x = myAlloc(x);

    >>
    >> While it is possible to write evil code in which myAlloc could modify x,
    >> in C myAlloc receives a copy of the value of x and has no clue where x
    >> is or how to modify it. ?There are not two or more instances of
    >> modifying x between sequence points.
    >>

    >
    > What is the scope of 'x' in myAlloc(x)? Is confined to myAlloc()?


    Assuming that myAlloc() is a function and not a macro, yes. Function
    parameters act as local variables within the function block and anything
    done to them within that block does not affect anything outside.

    The exception to this is of course if x is a pointer, then it is
    possible from within the function to modify the data that x points to.


    --
    The perfected state of a spam server is a smoking crater.
    - The Crater Corollary to Rule #4
     
    Angel, May 2, 2011
    #6
  7. arnuld

    Tim Rentsch Guest

    arnuld <> writes:

    > I have this program which is causing confusion to me. I am told that last
    > printf() of main() will always print "Second", not "First". I think line:
    >
    > x = myAlloc(x);
    >
    > is UB. [snip elaboration]


    If x is a variable and myAlloc(x) is a function call (ie, and
    neither x nor myAlloc() is a macro), there is _no way_ this
    assignment statement can be undefined behavior (assuming of
    course that calling myAlloc() doesn't wander into UB-land just by
    itself).

    That result holds no matter whether x is of pointer type
    or not.

    Perhaps you were thinking of a different example? What's
    the smallest, simplest example program that demonstrates
    what you think the problem is?
     
    Tim Rentsch, May 2, 2011
    #7
  8. On Mon, 02 May 2011 07:38:53 -0400, arnuld <> wrote:

    ....
    > x = myAlloc(x);


    > char* myAlloc(char* c)
    > {
    > c = malloc(SIZE_LIMIT * sizeof *c);

    ....
    > return c;
    > }


    As has been pointed out, there's no way that myAlloc can possibly do
    anything to the value of x. Perhaps what you were thinking of is the
    possibility of undefined behavior in

    x = myAlloc(&x);
    ....
    char * myAlloc(char **c)
    {
    *c = malloc(SIZE_LIMIT);
    etc.

    but there's no undefined behavior here, either, because the function call
    inserts multiple sequence points before the assignment to x.
    --
    Morris Keesan --
     
    Morris Keesan, May 3, 2011
    #8
  9. arnuld

    James Kuyper Guest

    On 05/02/2011 12:36 PM, Chad wrote:
    > On May 2, 6:58�am, Martin Ambuhl <> wrote:
    >> On 5/2/2011 7:38 AM, arnuld wrote:
    >>
    >>> I have this program which is causing confusion to me. I am told that last
    >>> printf() of main() will always print "Second", not "First". I think line:

    >>
    >>> � x = myAlloc(x);

    >>
    >> While it is possible to write evil code in which myAlloc could modify x,
    >> in C myAlloc receives a copy of the value of x and has no clue where x
    >> is or how to modify it. �There are not two or more instances of
    >> modifying x between sequence points.
    >>

    >
    > What is the scope of 'x' in myAlloc(x)? Is confined to myAlloc()?


    The scope of 'x' starts at the declaration of 'x' on the first line of
    main(), and is restricted to the body of main(). It goes out of scope
    throughout the execution of myAlloc(). It comes back into scope after
    that function returns. It's scope ends when main() returns.

    --
    James Kuyper
     
    James Kuyper, May 3, 2011
    #9
  10. James Kuyper <> writes:
    > On 05/02/2011 12:36 PM, Chad wrote:
    >> On May 2, 6:58�am, Martin Ambuhl <> wrote:
    >>> On 5/2/2011 7:38 AM, arnuld wrote:
    >>>
    >>>> I have this program which is causing confusion to me. I am told that last
    >>>> printf() of main() will always print "Second", not "First". I think line:
    >>>
    >>>> � x = myAlloc(x);
    >>>
    >>> While it is possible to write evil code in which myAlloc could modify x,
    >>> in C myAlloc receives a copy of the value of x and has no clue where x
    >>> is or how to modify it. �There are not two or more instances of
    >>> modifying x between sequence points.
    >>>

    >>
    >> What is the scope of 'x' in myAlloc(x)? Is confined to myAlloc()?

    >
    > The scope of 'x' starts at the declaration of 'x' on the first line of
    > main(), and is restricted to the body of main(). It goes out of scope
    > throughout the execution of myAlloc(). It comes back into scope after
    > that function returns. It's scope ends when main() returns.


    Your wording seems to imply that 'x' goes into and out of scope
    during execution. In fact, an entity's scope is a region of
    program text. C99 6.2.1p2.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 3, 2011
    #10
  11. arnuld

    James Kuyper Guest

    On 05/03/2011 02:26 AM, Keith Thompson wrote:
    > James Kuyper <> writes:
    >> On 05/02/2011 12:36 PM, Chad wrote:
    >>> On May 2, 6:58�am, Martin Ambuhl <> wrote:
    >>>> On 5/2/2011 7:38 AM, arnuld wrote:
    >>>>
    >>>>> I have this program which is causing confusion to me. I am told that last
    >>>>> printf() of main() will always print "Second", not "First". I think line:
    >>>>
    >>>>> � x = myAlloc(x);
    >>>>
    >>>> While it is possible to write evil code in which myAlloc could modify x,
    >>>> in C myAlloc receives a copy of the value of x and has no clue where x
    >>>> is or how to modify it. �There are not two or more instances of
    >>>> modifying x between sequence points.
    >>>>
    >>>
    >>> What is the scope of 'x' in myAlloc(x)? Is confined to myAlloc()?

    >>
    >> The scope of 'x' starts at the declaration of 'x' on the first line of
    >> main(), and is restricted to the body of main(). It goes out of scope
    >> throughout the execution of myAlloc(). It comes back into scope after
    >> that function returns. It's scope ends when main() returns.

    >
    > Your wording seems to imply that 'x' goes into and out of scope
    > during execution. In fact, an entity's scope is a region of
    > program text. C99 6.2.1p2.


    As the program executes, it executes code corresponding to those
    different regions of text, and that's what I was trying to talk about.
    However, that correspondence gets complicated to talk about accurately,
    especially after optimization. I should really have emphasized that
    scope is a compile-time concept, not a run-time one.

    The key point is that that all of the operations that might, in some
    other context, be problematic, are performed on a variable named 'c',
    whose scope is restricted to myAlloc(), that happens to be initialized
    with the value of 'x' at the time myAlloc() is called. As a result,
    they're not at all problematic.
    --
    James Kuyper
     
    James Kuyper, May 3, 2011
    #11
  12. arnuld

    Phil Carmody Guest

    Kenneth Brody <> writes:

    > On 5/2/2011 9:58 AM, Martin Ambuhl wrote:
    > > On 5/2/2011 7:38 AM, arnuld wrote:
    > >> I have this program which is causing confusion to me. I am told that last
    > >> printf() of main() will always print "Second", not "First". I think line:
    > >>
    > >> x = myAlloc(x);

    > >
    > > While it is possible to write evil code in which myAlloc could modify x, in
    > > C myAlloc receives a copy of the value of x and has no clue where x is or
    > > how to modify it. There are not two or more instances of modifying x between
    > > sequence points.

    >
    > But, unless I'm badly mistaken (and I know I'll be told so if I am),
    > the call to and a return from a function are sequence points.
    > Therefore, as long as myAlloc() is a function and not a macro, even
    > this does not invoke UB:
    >
    > x = myAlloc(x++);
    >
    > >> is UB. My colleague is disagreeing on this while I was saying that its UB
    > >> because there is no sequence point here. It is just like using this line:

    >
    > The function call is a sequence point.


    At least 2. One between the evaluation of the parameters and the call, and
    one at the return of the function.

    Phil
    --
    "At least you know where you are with Microsoft."
    "True. I just wish I'd brought a paddle." -- Matthew Vernon
     
    Phil Carmody, May 3, 2011
    #12
  13. On May 2, 8:55 pm, "Morris Keesan" <> wrote:
    > On Mon, 02 May 2011 07:38:53 -0400, arnuld <> wrote:
    >
    > ...
    >
    >
    >
    > >   x = myAlloc(x);
    > > char* myAlloc(char* c)
    > > {
    > >   c = malloc(SIZE_LIMIT * sizeof *c);

    > ...
    > >   return c;
    > > }

    >
    > As has been pointed out, there's no way that myAlloc can possibly do
    > anything to the value of x.  Perhaps what you were thinking of is the
    > possibility of undefined behavior in
    >
    > x = myAlloc(&x);
    > ...
    > char * myAlloc(char **c)
    > {
    >     *c = malloc(SIZE_LIMIT);
    >     etc.
    >
    > but there's no undefined behavior here, either, because the function call
    > inserts multiple sequence points before the assignment to x.
    > --
    > Morris Keesan --


    A more contrived version which has a problem is this:

    #include <string.h>
    #include <stdlib.h>

    typedef struct foo
    {
    struct foo *next;
    } foo;

    struct foo *badness(foo** ouch)
    {
    *ouch = realloc(*ouch, 1000);
    return *ouch;
    }

    int main(void)
    {
    struct foo *pFoo = malloc(sizeof *pFoo);
    pFoo->next = badness(&pFoo);
    return 0;
    }

    Once had bogus code that did something like that with a static
    variable, alas. Worked with older version of gcc, as it figured out
    LHS after the function call. Newer version evaluated LHS before
    function call. UB is like that sometimes...

    -David
     
    David Resnick, May 3, 2011
    #13
    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. Sensorflo
    Replies:
    3
    Views:
    602
    Ron Natalie
    Aug 19, 2004
  2. stef mientki
    Replies:
    13
    Views:
    644
    stef mientki
    Oct 20, 2007
  3. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    681
  4. Saraswati lakki
    Replies:
    0
    Views:
    1,344
    Saraswati lakki
    Jan 6, 2012
  5. regis
    Replies:
    63
    Views:
    557
    Seebs
    Nov 21, 2013
Loading...

Share This Page