Question regarding sequence point

S

somenath

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
 
J

Jack Klein

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
 
S

somenath

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
 
C

CBFalconer

somenath said:
.... snip ...

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/~wijnands/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>
 
S

santosh

somenath said:
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'.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,989
Messages
2,570,207
Members
46,782
Latest member
ThomasGex

Latest Threads

Top