Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why is this expression detected as undefined by GCC, Splint?

Reply
Thread Tools

Why is this expression detected as undefined by GCC, Splint?

 
 
amuro
Guest
Posts: n/a
 
      12-30-2010
Hi, I wonder why the following expression is detected as undefined
expression. In my opinion, this is a "defined" expression.

x = *(x++, p); // line 21

$ gcc -Wsequence-point test.c
test.1:21: warning: operation on 'x' may be undefined

$ splint test.c
test.c:21:6: Expression has undefined behavior (value of left operand
x is modified by right operand *(x++, p)): x = *(x++, p)

Another expression looks similar with previous expression shows
expected result by GCC but not Splint. That means GCC does not
consider it as undefined but Splint considers it as undefined
expression.

x = (x++, y); // line 19

$ splint test.c
test.c:19:6: Expression has undefined behavior (value of left operand
x is modified by right operand (x++, y)): x = (x++, y)

Thx in advance.
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      12-30-2010
On Dec 30, 6:50*am, amuro <(E-Mail Removed)> wrote:
> Hi, I wonder why the following expression is detected as undefined
> expression. In my opinion, this is a "defined" expression.
>
> x = *(x++, p); *// line 21
>
> $ gcc -Wsequence-point test.c
> test.1:21: warning: operation on 'x' may be undefined
>
> $ splint test.c
> test.c:21:6: Expression has undefined behavior (value of left operand
> x is modified by right operand *(x++, p)): x = *(x++, p)
>
> Another expression looks similar with previous expression shows
> expected result by GCC but not Splint. That means GCC does not
> consider it as undefined


it may be that gcc does not *detect* that it is undefined. A compiler
is not obliged to diagnose undefined behaviour. A compiler isn't
obliged to do *anything* specific with undefined behaviour. After all
the behaviour is not defined...

> but Splint considers it as undefined
> expression.
>
> x = (x++, y); *// line 19
>
> $ splint test.c
> test.c:19:6: Expression has undefined behavior (value of left operand
> x is modified by right operand (x++, y)): x = (x++, y)
>
> Thx in advance.


 
Reply With Quote
 
 
 
 
amuro
Guest
Posts: n/a
 
      12-30-2010
On 12월30일, 오후4시00분, Nick Keighley <(E-Mail Removed)>
wrote:
> On Dec 30, 6:50 am, amuro <(E-Mail Removed)> wrote:
>
> > Hi, I wonder why the following expression is detected as undefined
> > expression. In my opinion, this is a "defined" expression.

>
> > x = *(x++, p); // line 21

>
> > $ gcc -Wsequence-point test.c
> > test.1:21: warning: operation on 'x' may be undefined

>
> > $ splint test.c
> > test.c:21:6: Expression has undefined behavior (value of left operand
> > x is modified by right operand *(x++, p)): x = *(x++, p)

>
> > Another expression looks similar with previous expression shows
> > expected result by GCC but not Splint. That means GCC does not
> > consider it as undefined

>
> it may be that gcc does not *detect* that it is undefined. A compiler
> is not obliged to diagnose undefined behaviour. A compiler isn't
> obliged to do *anything* specific with undefined behaviour. After all
> the behaviour is not defined...


Thank you for reply. You're right that a compiler is not obliged to
diagnose undefined behaviour.
I'd like to change my question. Does the expression, "x = *(x++, p);"
result in undefined behavior in terms of C Specification?

 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      12-30-2010
On Dec 30, 1:06 am, amuro <(E-Mail Removed)> wrote:
> On 12월30일, 오후4시00분, Nick Keighley <(E-Mail Removed)>
> wrote:
>
>
>
>
>
> > On Dec 30, 6:50 am, amuro <(E-Mail Removed)> wrote:

>
> > > Hi, I wonder why the following expression is detected as undefined
> > > expression. In my opinion, this is a "defined" expression.

>
> > > x = *(x++, p); // line 21

>
> > > $ gcc -Wsequence-point test.c
> > > test.1:21: warning: operation on 'x' may be undefined

>
> > > $ splint test.c
> > > test.c:21:6: Expression has undefined behavior (value of left operand
> > > x is modified by right operand *(x++, p)): x = *(x++, p)

>
> > > Another expression looks similar with previous expression shows
> > > expected result by GCC but not Splint. That means GCC does not
> > > consider it as undefined

>
> > it may be that gcc does not *detect* that it is undefined. A compiler
> > is not obliged to diagnose undefined behaviour. A compiler isn't
> > obliged to do *anything* specific with undefined behaviour. After all
> > the behaviour is not defined...

>
> Thank you for reply. You're right that a compiler is not obliged to
> diagnose undefined behaviour.
> I'd like to change my question. Does the expression, "x = *(x++, p);"
> result in undefined behavior in terms of C Specification?



Yes. You cannot modify a variable twice between sequence points,
since there is no order defined. IOW, "*(x++, p)" may be reasonably
defined, but the time at which the ++ happens relative to the
assignment into x is *not*.
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      12-30-2010
On 30 Dec 2010 01:51, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On Dec 30, 1:06 am, amuro <(E-Mail Removed)> wrote:
>> On 12썡30씪, 삤썑4떆00遺, Nick Keighley <(E-Mail Removed)>
>> wrote:
>>
>>
>>
>>
>>
>>> On Dec 30, 6:50 am, amuro <(E-Mail Removed)> wrote:

>>
>>>> Hi, I wonder why the following expression is detected as undefined
>>>> expression. In my opinion, this is a "defined" expression.

>>
>>>> x = *(x++, p); // line 21

>>
>>>> $ gcc -Wsequence-point test.c
>>>> test.1:21: warning: operation on 'x' may be undefined

>>
>>>> $ splint test.c
>>>> test.c:21:6: Expression has undefined behavior (value of left operand
>>>> x is modified by right operand *(x++, p)): x = *(x++, p)

>>
>>>> Another expression looks similar with previous expression shows
>>>> expected result by GCC but not Splint. That means GCC does not
>>>> consider it as undefined

>>
>>> it may be that gcc does not *detect* that it is undefined. A compiler
>>> is not obliged to diagnose undefined behaviour. A compiler isn't
>>> obliged to do *anything* specific with undefined behaviour. After all
>>> the behaviour is not defined...

>>
>> Thank you for reply. You're right that a compiler is not obliged to
>> diagnose undefined behaviour.
>> I'd like to change my question. Does the expression, "x = *(x++, p);"
>> result in undefined behavior in terms of C Specification?

>
>
> Yes. You cannot modify a variable twice between sequence points,
> since there is no order defined. IOW, "*(x++, p)" may be reasonably
> defined, but the time at which the ++ happens relative to the
> assignment into x is *not*.


The comma's introduces a sequence point between the evaluations of x++
and p, and the assignment cannot be evaluated until after p is
evaluated, so how is the behavior undefined? AFAICT, that expression
must have identical behavior to the well-defined "x++; x = *p;".

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
amuro
Guest
Posts: n/a
 
      12-30-2010
> Yes. ?You cannot modify a variable twice between sequence points,
> since there is no order defined. ?IOW, "*(x++, p)" may be reasonably
> defined, but the time at which the ++ happens relative to the
> assignment into x is *not*.


Hm.. Is the assignment to x sequenced after post-increment of x?

By "6.5.16p3 Assignment operators", "The side effect of updating the
stored value of
the left operand is sequenced after the value computations of the left
and right operands."

Evaluation consists of value computation and initiation of side
effect. Value computation
can be cosidered as evaluation except applying side effect. (5.1.2.3p2
Program execution)

So in the expression "x = *(x++, p)", assignment to x is sequenced
after the value computation
of right operand "*(x++, p)". It does not mean assignment to x is
sequenced after the side effect
of right operand. But, during value computation, it causes sequence
point. After all,
the assignement to x is sequenced after the side effect of post-
increment of x.
That means those two side effect actions are not in between two
sequence points.
 
Reply With Quote
 
amuro
Guest
Posts: n/a
 
      12-30-2010
On 12월30일, 오후5시43분, amuro <(E-Mail Removed)> wrote:
> > Yes. ?You cannot modify a variable twice between sequence points,
> > since there is no order defined. ?IOW, "*(x++, p)" may be reasonably
> > defined, but the time at which the ++ happens relative to the
> > assignment into x is *not*.

>
> Hm.. Is the assignment to x sequenced after post-increment of x?
>
> By "6.5.16p3 Assignment operators", "The side effect of updating the
> stored value of
> the left operand is sequenced after the value computations of the left
> and right operands."
>
> Evaluation consists of value computation and initiation of side
> effect. Value computation
> can be cosidered as evaluation except applying side effect. (5.1.2.3p2
> Program execution)
>
> So in the expression "x = *(x++, p)", assignment to x is sequenced
> after the value computation
> of right operand "*(x++, p)". It does not mean assignment to x is
> sequenced after the side effect
> of right operand. But, during value computation, it causes sequence
> point. After all,
> the assignement to x is sequenced after the side effect of post-
> increment of x.
> That means those two side effect actions are not in between two
> sequence points.


I'v cited C draft, Committee draft, Nov 16, 2010 at
http://www.open-std.org/jtc1/sc22/wg...docs/n1539.pdf
 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      12-30-2010
On 2010-12-30, Stephen Sprunk <(E-Mail Removed)> wrote:
> [ about x = *(x++, p); ]
> The comma's introduces a sequence point between the evaluations of x++
> and p, and the assignment cannot be evaluated until after p is
> evaluated, so how is the behavior undefined? AFAICT, that expression
> must have identical behavior to the well-defined "x++; x = *p;".


You are probably thinking of the (acceptable) sequence of evaluations:

x++ , p , * , lhs x , =

But the evaluation of the lefthandside of the assigment (``lhs x'')
can happen before ``x++'' on the righthandside is evaluated, so
this is also an accecptable sequence of evaluations:

lhs x , x++ , p , * , =

with behaviour identical to the well-defined ``x = *p; x++;'' .
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-30-2010
On 12/30/2010 1:50 AM, amuro wrote:
> Hi, I wonder why the following expression is detected as undefined
> expression. In my opinion, this is a "defined" expression.
>
> x = *(x++, p); // line 21


Undefined behavior: `x' is modified twice without an intervening
sequence point.

Yes, there's a sequence point between `x++' and `p'. But there's
no sequence point between `x=' and `x++'.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
amuro
Guest
Posts: n/a
 
      12-30-2010
On 12월30일, 오후10시18분, Eric Sosman <(E-Mail Removed)> wrote:
> On 12/30/2010 1:50 AM, amuro wrote:
>
> > Hi, I wonder why the following expression is detected as undefined
> > expression. In my opinion, this is a "defined" expression.

>
> > x = *(x++, p); // line 21

>
> Undefined behavior: `x' is modified twice without an intervening
> sequence point.
>
> Yes, there's a sequence point between `x++' and `p'. But there's
> no sequence point between `x=' and `x++'.


[about x = *(x++, p);]

I think it can be derived that there exists sequence point between
`x=`(assignment) and side effect generated by 'x++' with respect to
all the possible(acceptable) evaluation sequences.

* "a > b" means that b is sequenced before a

'x=' > value computation of LHS and RHS of x= which requires
"evaluating p" // by 6.5.16p3
"evaluating p" > side effect by x+
+ // by comma op

Therefore.. 'x=' is sequenced before side effect of x++.
IOW, there's a sequence point between 'x=' and 'x++'..
 
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
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C++ 42 11-04-2008 12:39 PM
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C Programming 45 11-04-2008 12:39 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
undefined behavior or not undefined behavior? That is the question Mantorok Redgormor C Programming 70 02-17-2004 02:46 PM



Advertisments