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

Discussion in 'C Programming' started by amuro, Dec 30, 2010.

  1. amuro

    amuro Guest

    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.
    amuro, Dec 30, 2010
    #1
    1. Advertising

  2. On Dec 30, 6: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
    >
    > $ 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.
    Nick Keighley, Dec 30, 2010
    #2
    1. Advertising

  3. amuro

    amuro Guest

    On 12¿ù30ÀÏ, ¿ÀÈÄ4½Ã00ºÐ, Nick Keighley <>
    wrote:
    > On Dec 30, 6: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

    >
    > > $ 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?
    amuro, Dec 30, 2010
    #3
  4. amuro

    Guest

    On Dec 30, 1:06 am, amuro <> wrote:
    > On 12¿ù30ÀÏ, ¿ÀÈÄ4½Ã00ºÐ, Nick Keighley <>
    > wrote:
    >
    >
    >
    >
    >
    > > On Dec 30, 6: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

    >
    > > > $ 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*.
    , Dec 30, 2010
    #4
  5. On 30 Dec 2010 01:51, wrote:
    > On Dec 30, 1:06 am, amuro <> wrote:
    >> On 12ì›”30ì¼, 오후4ì‹œ00분, Nick Keighley <>
    >> wrote:
    >>
    >>
    >>
    >>
    >>
    >>> On Dec 30, 6: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

    >>
    >>>> $ 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
    Stephen Sprunk, Dec 30, 2010
    #5
  6. amuro

    amuro Guest

    > 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.
    amuro, Dec 30, 2010
    #6
  7. amuro

    amuro Guest

    On 12¿ù30ÀÏ, ¿ÀÈÄ5½Ã43ºÐ, amuro <> 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/wg14/www/docs/n1539.pdf
    amuro, Dec 30, 2010
    #7
  8. amuro

    Ike Naar Guest

    On 2010-12-30, Stephen Sprunk <> 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++;'' .
    Ike Naar, Dec 30, 2010
    #8
  9. amuro

    Eric Sosman Guest

    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
    lid
    Eric Sosman, Dec 30, 2010
    #9
  10. amuro

    amuro Guest

    On 12¿ù30ÀÏ, ¿ÀÈÄ10½Ã18ºÐ, Eric Sosman <> 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++'..
    amuro, Dec 30, 2010
    #10
  11. amuro

    Eric Sosman Guest

    On 12/30/2010 9:43 AM, amuro wrote:
    > On 12ì›”30ì¼, 오후10ì‹œ18분, Eric Sosman<> 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++'..


    "A must be evaluated before B" does not imply that "there is
    a sequence point between A and B." Yes, "before" and "sequence"
    sound as if they refer to the same notion of order, but keep in
    mind that the Standard is a technical document and uses language
    in a technical sense. "Sequence point," in the Standard, means
    exactly and only what its definition (5.1.2.3p2) says -- and what
    the definition says is that an SP is a *specified* point, that is,
    there's an SP where the Standard *specifies* one, period. Those
    specifications are scattered throughout the Standard (and summarized
    in Annex C), and those are the *only* SP specifications.

    The reason (or *a* reason) for all this hair-splitting is that
    the Standard tries to describe the meaning of a C program without
    reference to the implementation. By divorcing the notion of SP from
    the notion of "order of operation," the Standard can talk about the
    meaning without hobbling the compiler and inhibiting optimizations.

    --
    Eric Sosman
    lid
    Eric Sosman, Dec 30, 2010
    #11
  12. On 30 Dec 2010 04:03, Ike Naar wrote:
    > On 2010-12-30, Stephen Sprunk <> 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++;'' .


    Ah; that explains it. Thanks.

    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
    Stephen Sprunk, Dec 30, 2010
    #12
  13. amuro

    Seebs Guest

    On 2010-12-30, amuro <> wrote:
    > I'v cited C draft, Committee draft, Nov 16, 2010 at
    > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf


    And that means your argument will suddenly become relevant when you
    have a C1X compiler. :)

    I think that's an improvement to the language, but right now it's
    not there.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Dec 30, 2010
    #13
  14. amuro <> writes:
    > On 12ì›”30ì¼, 오후5ì‹œ43분, amuro <> 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/wg14/www/docs/n1539.pdf


    Yes, I thought you were quoting a C201X draft; C99 doesn't use the
    "sequenced after" wording.

    There's a newer draft, n1547.pdf, available from the same source.

    But the C201X documents are drafts of the new standard, not of the
    current C99 standard. There are no compilers that conform to C201X,
    since it doesn't exist yet. (Finding conforming C99 compilers is hard
    enough.)

    C201X changes the description of sequence points. IMHO the new wording
    is clearer, and I think it's intended to describe the same underlying
    semantics. But if you want a document that describes the language as
    it's currently defined, you'll want n1256.pdf.

    --
    Keith Thompson (The_Other_Keith) <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"
    Keith Thompson, Dec 30, 2010
    #14
  15. amuro

    amuro Guest

    On 12ì›”31ì¼, 오전1ì‹œ54분, Eric Sosman <> wrote:
    > On 12/30/2010 9:43 AM, amuro wrote:
    >
    >
    >
    >
    >
    > > On 12ì›”30ì¼, 오후10ì‹œ18분, Eric Sosman<>  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++'..

    >
    >      "A must be evaluated before B" does not imply that "there is
    > a sequence point between A and B."  Yes, "before" and "sequence"
    > sound as if they refer to the same notion of order, but keep in
    > mind that the Standard is a technical document and uses language
    > in a technical sense.  "Sequence point," in the Standard, means
    > exactly and only what its definition (5.1.2.3p2) says -- and what
    > the definition says is that an SP is a *specified* point, that is,
    > there's an SP where the Standard *specifies* one, period.  Those
    > specifications are scattered throughout the Standard (and summarized
    > in Annex C), and those are the *only* SP specifications.


    Thank you for pointing out my misled statement. As you mentioned,
    "A must be evaluated before B" does not imply that "there is
    a sequence point between A and B.".
    Precisely, the following would be my intention.
    (1) A is sequenced after B *AND* (2) there exists a SP between A and
    B.
    Those two conditions seem to meet escaping from the undefinedness.

    Does the presence of partial ordering such as "sequenced before/
    after"
    may give the restricted position of SP in evaluation sequences?

    e.g) A -> .... -> SP -> .. -> B

    comma operator gives the partial order of both operands *AND*
    SP between both operands. (b)

    'x=' > evaluating p // --- (a)
    evaluating p > SP > 'x++' // --- (b)
    By those two constraints (a),(b), all possible evaluation sequences
    should be like the following.

    'x++' -> incrementing x -> .. SP -> p-> 'x='

    The difference between your statement and mine seems to be the
    interpretation of effect of SP. I've extended(?) the effect of SP
    in terms of whole evaluation sequences. So SP splits the whole
    evaluation sequence by previous and next from the position of SP.
    Not just point between both operands for example comma operator.
    amuro, Dec 30, 2010
    #15
  16. amuro

    amuro Guest

    On 12ì›”31ì¼, 오전4ì‹œ40분, Keith Thompson <> wrote:
    > amuro <> writes:
    > > On 12ì›”30ì¼, 오후5ì‹œ43분, amuro <> 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/wg14/www/docs/n1539.pdf

    >
    > Yes, I thought you were quoting a C201X draft; C99 doesn't use the
    > "sequenced after" wording.
    >
    > There's a newer draft, n1547.pdf, available from the same source.
    >
    > But the C201X documents are drafts of the new standard, not of the
    > current C99 standard.  There are no compilers that conform to C201X,
    > since it doesn't exist yet.  (Finding conforming C99 compilers is hard
    > enough.)
    >
    > C201X changes the description of sequence points.  IMHO the new wording
    > is clearer, and I think it's intended to describe the same underlying
    > semantics.  But if you want a document that describes the language as
    > it's currently defined, you'll want n1256.pdf.
    >
    > --
    > Keith Thompson (The_Other_Keith)  <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"


    Thank you! I would check n1547.pdf.
    amuro, Dec 30, 2010
    #16
  17. amuro

    amuro Guest

    On 12¿ù31ÀÏ, ¿ÀÀü4½Ã23ºÐ, Seebs <> wrote:
    > On 2010-12-30, amuro <> wrote:
    >
    > > I'v cited C draft, Committee draft, Nov 16, 2010 at
    > >http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf

    >
    > And that means your argument will suddenly become relevant when you
    > have a C1X compiler. :)
    >
    > I think that's an improvement to the language, but right now it's
    > not there.
    >
    > -s
    > --
    > Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs..nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    > I am not speaking for my employer, although they do rent some of my opinions.

    Yes. you're right. Hm.. the reason why I've cited is that it seems to
    be more clear than n1256.
    Thanks.
    amuro, Dec 30, 2010
    #17
  18. amuro

    Seebs Guest

    On 2010-12-30, amuro <> wrote:
    > Yes. you're right. Hm.. the reason why I've cited is that it seems to
    > be more clear than n1256.


    Well, yes. That's one of the points of the revision. However, in some
    cases, it will make a thing clear which *isn't true* in the old document.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Dec 30, 2010
    #18
  19. amuro

    Tim Rentsch Guest

    Ike Naar <> writes:

    > On 2010-12-30, Stephen Sprunk <> 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 , * , =


    This statement is correct.

    > with behaviour identical to the well-defined ``x = *p; x++;'' .


    This statement is not correct. The expression 'lhs x' is
    not affected by 'x++' so it doesn't matter whether 'x++'
    is evaluated before or after 'lhs x'.
    Tim Rentsch, Jan 2, 2011
    #19
  20. amuro

    Tim Rentsch Guest

    Seebs <> writes:

    > On 2010-12-30, amuro <> wrote:
    >> Yes. you're right. Hm.. the reason why I've cited is that it seems to
    >> be more clear than n1256.

    >
    > Well, yes. That's one of the points of the revision. However, in some
    > cases, it will make a thing clear which *isn't true* in the old document.


    Except in this case the point made clear _is_ true in the old
    document. And C89 as well.
    Tim Rentsch, Jan 2, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Greg Roberts

    Using splint on C files under MS VC6

    Greg Roberts, Jan 23, 2004, in forum: C Programming
    Replies:
    0
    Views:
    448
    Greg Roberts
    Jan 23, 2004
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,805
    Smokey Grindel
    Dec 2, 2006
  3. Guy Eschemann

    "Implicitly only" splint warnings

    Guy Eschemann, Jan 12, 2005, in forum: C Programming
    Replies:
    2
    Views:
    1,367
    Guy Eschemann
    Jan 13, 2005
  4. Henry Fr?d?ric

    Ignore include header files with Splint

    Henry Fr?d?ric, Mar 23, 2005, in forum: C Programming
    Replies:
    8
    Views:
    1,168
    Tor Rustad
    Mar 29, 2005
  5. Peter Bencsik
    Replies:
    2
    Views:
    822
Loading...

Share This Page