Pointers and Sequence Point

[arnuld]

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]$

 

[James Kuyper]

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.

 

[Martin Ambuhl]

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.

 

[Chad]

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

 

[John Bode]

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.

 

[Angel]

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.

 

[Tim Rentsch]

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?

 

[Morris Keesan]

....

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.

 

[James Kuyper]

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.

 

[Keith Thompson]

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.

 

[James Kuyper]

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.

 

[Phil Carmody]

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++);


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

 

[David Resnick]

...




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.

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