Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Question regarding sequence point

Reply
Thread Tools

Question regarding sequence point

 
 
somenath
Guest
Posts: n/a
 
      11-26-2007
Hi All,
I have one question regarding the code mentioned bellow.

#include<stdio.h>
int main(void)
{
unsigned int i = 5;
printf("\n i = %d i<<2 = %d i>>2 =%d\n",i,i<<=2,i>>=2);
return 0;

}

The output of the following code is as mentioned bellow.
i = 4 i<<2 = 4 i>>2 =1

I know the behavior of the code is undefined because
1) Order of evaluation of function arguments are not defined by C
standard.
My question is
Does the following code not trying to modify the value of "i " with
in one sequence point ?

Regards,
Somenath
 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      11-26-2007
On Sun, 25 Nov 2007 18:47:04 -0800 (PST), somenath
<(E-Mail Removed)> wrote in comp.lang.c:

> Hi All,
> I have one question regarding the code mentioned bellow.
>
> #include<stdio.h>
> int main(void)
> {
> unsigned int i = 5;
> printf("\n i = %d i<<2 = %d i>>2 =%d\n",i,i<<=2,i>>=2);
> return 0;
>
> }
>
> The output of the following code is as mentioned bellow.
> i = 4 i<<2 = 4 i>>2 =1
>
> I know the behavior of the code is undefined because
> 1) Order of evaluation of function arguments are not defined by C
> standard.


Actually, that is both not true and does not make the behavior
undefined. The order of evaluation of function arguments is
"unspecified" by the C standard, which is a distinct type of behavior
completely different than "undefined".

Unspecified behavior means that the compiler (or more specifically,
the programmers who wrote the compiler) must pick some order, but they
do not have to document what it is, nor does it have to be consistent.

Consider:

#include <stdio.h>

int val(void)
{
static int x = 3;
return x++;
}

int main(void)
{
printf("%d %d\n", val(), val());
return 0;
}

This code has "unspecified behavior", but not "undefined behavior".
The compiler must generate code to call val() twice. The result of
one of these calls is passed as the second argument to printf(), the
result of the other call is passed as the third argument to printf().

The output can be either:

3 4

....or

4 3

....and the compiler documentation does not have to specify which. In
fact it may change from one to the other when the compiler is invoked
with different options.

There is no undefined behavior here, because each time the value of
'x' is modified, it is inside its own function, which introduces a
sequence point.

And since there is no undefined behavior involved, the program must
output one of these two sequences here, there are no other
possibilities allowed.

> My question is
> Does the following code not trying to modify the value of "i " with
> in one sequence point ?


In fact, the one and only reason your code example has undefined
behavior is because it violates two rules relating to sequence points,
not just one.

First, the value of 'i' is indeed modified twice without an
intervening sequence point.

Second, the value of 'i' is accessed other than in to determine its
new value.

> Regards,
> Somenath


--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
Reply With Quote
 
 
 
 
somenath
Guest
Posts: n/a
 
      11-26-2007
On Nov 26, 8:08 am, Jack Klein <(E-Mail Removed)> wrote:
> On Sun, 25 Nov 2007 18:47:04 -0800 (PST), somenath
> <(E-Mail Removed)> wrote in comp.lang.c:
>
>
>
>
>
> > Hi All,
> > I have one question regarding the code mentioned bellow.

>
> > #include<stdio.h>
> > int main(void)
> > {
> > unsigned int i = 5;
> > printf("\n i = %d i<<2 = %d i>>2 =%d\n",i,i<<=2,i>>=2);
> > return 0;

>
> > }

>
> > The output of the following code is as mentioned bellow.
> > i = 4 i<<2 = 4 i>>2 =1

>
> > I know the behavior of the code is undefined because
> > 1) Order of evaluation of function arguments are not defined by C
> > standard.

>
> Actually, that is both not true and does not make the behavior
> undefined. The order of evaluation of function arguments is
> "unspecified" by the C standard, which is a distinct type of behavior
> completely different than "undefined".
>

Many thanks for your response. I would like to illustrate why I have
said "undefined" .
The while I compiled the code using gcc -Wall I got the following
warnings

gcc -Wall ub.c
ub.c: In function `main':
ub.c:5: warning: operation on `i' may be undefined
ub.c:5: warning: operation on `i' may be undefined



> Unspecified behavior means that the compiler (or more specifically,
> the programmers who wrote the compiler) must pick some order, but they
> do not have to document what it is, nor does it have to be consistent.
>
> Consider:
>
> #include <stdio.h>
>
> int val(void)
> {
> static int x = 3;
> return x++;
>
> }
>
> int main(void)
> {
> printf("%d %d\n", val(), val());
> return 0;
>
> }
>
> This code has "unspecified behavior", but not "undefined behavior".
> The compiler must generate code to call val() twice. The result of
> one of these calls is passed as the second argument to printf(), the
> result of the other call is passed as the third argument to printf().
>
> The output can be either:
>
> 3 4
>
> ...or
>
> 4 3
>
> ...and the compiler documentation does not have to specify which. In
> fact it may change from one to the other when the compiler is invoked
> with different options.
>
> There is no undefined behavior here, because each time the value of
> 'x' is modified, it is inside its own function, which introduces a
> sequence point.
>
> And since there is no undefined behavior involved, the program must
> output one of these two sequences here, there are no other
> possibilities allowed.
>
> > My question is
> > Does the following code not trying to modify the value of "i " with
> > in one sequence point ?

>
> In fact, the one and only reason your code example has undefined
> behavior is because it violates two rules relating to sequence points,
> not just one.
>
> First, the value of 'i' is indeed modified twice without an
> intervening sequence point.
>
> Second, the value of 'i' is accessed other than in to determine its
> new value.



 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-26-2007
somenath wrote:
> Jack Klein <(E-Mail Removed)> wrote:
>

.... snip ...
>>
>> Actually, that is both not true and does not make the behavior
>> undefined. The order of evaluation of function arguments is
>> "unspecified" by the C standard, which is a distinct type of
>> behavior completely different than "undefined".

>
> Many thanks for your response. I would like to illustrate why I
> have said "undefined" .
> The while I compiled the code using gcc -Wall I got the following
> warnings
>
> gcc -Wall ub.c
> ub.c: In function `main':
> ub.c:5: warning: operation on `i' may be undefined
> ub.c:5: warning: operation on `i' may be undefined


I have quoted your entire reply, together with what it responded
to. Your actual reply consisted of an entirely useless 106 lines,
whose main function was to hide your actual reply. Please quote
and snip correctly. See the links in my sig. below.

--
Some useful links on quoting:
<http://www.xs4all.nl/%7ewijnands/nnq/nquote.html>
<http://www.complang.tuwien.ac.at/anton/mail-news-errors.html>
<http://www.netmeister.org/news/learn2quote2.html>
<http://www.star-one.org.uk/computer/format.htm>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      11-26-2007
In article
<(E-Mail Removed)>,
somenath <(E-Mail Removed)> wrote on Monday 26 Nov 2007 9:14 am:

> On Nov 26, 8:08 am, Jack Klein <(E-Mail Removed)> wrote:
>> On Sun, 25 Nov 2007 18:47:04 -0800 (PST), somenath
>> <(E-Mail Removed)> wrote in comp.lang.c:
>>
>>
>>
>>
>>
>> > Hi All,
>> > I have one question regarding the code mentioned bellow.

>>
>> > #include<stdio.h>
>> > int main(void)
>> > {
>> > unsigned int i = 5;
>> > printf("\n i = %d i<<2 = %d i>>2 =%d\n",i,i<<=2,i>>=2);
>> > return 0;

>>
>> > }

>>
>> > The output of the following code is as mentioned bellow.
>> > i = 4 i<<2 = 4 i>>2 =1

>>
>> > I know the behavior of the code is undefined because
>> > 1) Order of evaluation of function arguments are not defined by C
>> > standard.

>>
>> Actually, that is both not true and does not make the behavior
>> undefined. The order of evaluation of function arguments is
>> "unspecified" by the C standard, which is a distinct type of behavior
>> completely different than "undefined".
>>

> Many thanks for your response. I would like to illustrate why I have
> said "undefined" .
> The while I compiled the code using gcc -Wall I got the following
> warnings
>
> gcc -Wall ub.c
> ub.c: In function `main':
> ub.c:5: warning: operation on `i' may be undefined
> ub.c:5: warning: operation on `i' may be undefined


That's because your function call does invoke undefined behaviour, but
not for the reason that you (seemingly) thought.

<snip>

PS. To get even more diagnostics and conformance add the '-W', '-ansi'
and '-pedantic' options to the gcc invocation. Of course, to compile
code using C99 features, use '-std=c99' instead of '-ansi'.

 
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
Question regarding sequence point in case of conditional operator somenath C Programming 4 12-14-2007 01:07 PM
Question regarding sequence point in case of conditional operator somenath C Programming 0 12-14-2007 10:01 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