[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Pointers and Sequence Point

arnuld

5/2/2011 11:39:00 AM

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
13 Answers

James Kuyper

5/2/2011 12:24:00 PM

0

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

Martin Ambuhl

5/2/2011 1:58:00 PM

0

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.

Chad

5/2/2011 4:36:00 PM

0

On May 2, 6:58 am, Martin Ambuhl <mamb...@earthlink.net> 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

John Bode

5/2/2011 5:18:00 PM

0

On May 2, 6:38 am, arnuld <sunr...@invalid.address> 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.

Angel

5/2/2011 5:21:00 PM

0

On 2011-05-02, Chad <cdalten@gmail.com> wrote:
> On May 2, 6:58?am, Martin Ambuhl <mamb...@earthlink.net> 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

Tim Rentsch

5/2/2011 5:32:00 PM

0

arnuld <sunrise@invalid.address> 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?

Kenneth Brody

5/2/2011 5:35:00 PM

0

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.

[...]

--
Kenneth Brody

Morris Keesan

5/3/2011 12:56:00 AM

0

On Mon, 02 May 2011 07:38:53 -0400, arnuld <sunrise@invalid.address> 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 -- mkeesan@post.harvard.edu

James Kuyper

5/3/2011 3:21:00 AM

0

On 05/02/2011 12:36 PM, Chad wrote:
> On May 2, 6:58�am, Martin Ambuhl <mamb...@earthlink.net> 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

Keith Thompson

5/3/2011 6:26:00 AM

0

James Kuyper <jameskuyper@verizon.net> writes:
> On 05/02/2011 12:36 PM, Chad wrote:
>> On May 2, 6:58�am, Martin Ambuhl <mamb...@earthlink.net> 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) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"