Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Pointers and Sequence Point

Reply
Thread Tools

Pointers and Sequence Point

 
 
arnuld
Guest
Posts: n/a
 
      05-02-2011
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
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      05-02-2011
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
 
Reply With Quote
 
 
 
 
Martin Ambuhl
Guest
Posts: n/a
 
      05-02-2011
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.

 
Reply With Quote
 
Chad
Guest
Posts: n/a
 
      05-02-2011
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
 
Reply With Quote
 
John Bode
Guest
Posts: n/a
 
      05-02-2011
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.
 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      05-02-2011
On 2011-05-02, 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()?


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
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      05-02-2011
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?
 
Reply With Quote
 
Morris Keesan
Guest
Posts: n/a
 
      05-03-2011
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 --
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      05-03-2011
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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-03-2011
James Kuyper <> 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- <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"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Share-Point-2010 ,Share-Point -2010 Training , Share-point-2010Hyderabad , Share-point-2010 Institute Saraswati lakki ASP .Net 0 01-06-2012 06:39 AM
pointers, pointers, pointers... cerr C Programming 12 04-07-2011 11:17 PM
how to iterate over sequence and non-sequence ? stef mientki Python 13 10-20-2007 10:21 AM
Scenario 5: IS-IS routing on Frame Relay Multi-point and Point-to-Point David Sudjiman Cisco 0 06-08-2006 09:11 AM
BOOT SEQUENCE (how to change boot sequence) bird Computer Support 13 12-24-2003 02:20 AM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57