Sequence points

Discussion in 'C Programming' started by j, Jul 23, 2003.

  1. j

    j Guest

    In a footnote in the c99 standard the following is labeled as
    undefined:

    a[i++] = i;

    And in the second clause of section 6.5 the following is stated:

    "Between the previous and next sequence point an object shall have its
    stored value modified at most once by the evaluation of an expression.
    Furthermore, the prior value shall be read only to determine the value
    to be stored. 70)"

    So my question is, how do they derive undefined behaviour from "a[i++]
    = i;" ?

    With, a[i++] = i; this is one expression and there is only one
    sequence point here, ';'.
    'i' has its value modified only once and that is in the subscript
    operator to designate which object the value of 'i', on the right side
    of the assignment operator, will be stored at.

    But, I am guessing I am missing something here. So if anyone could
    enlighten me it would be much appreciated :)


    Also, what is the difference between unspecified behaviour and
    undefined behaviour? The standard attempts to make a distinction
    between the two in Annex J but my dictionary gives the same definition
    for "unspecified" and "undefined" so I fail to see how they can be
    used to describe certain things as though they were different.
    j, Jul 23, 2003
    #1
    1. Advertising

  2. j

    Eric Sosman Guest

    j wrote:
    >
    > In a footnote in the c99 standard the following is labeled as
    > undefined:
    >
    > a[i++] = i;
    >
    > And in the second clause of section 6.5 the following is stated:
    >
    > "Between the previous and next sequence point an object shall have its
    > stored value modified at most once by the evaluation of an expression.
    > Furthermore, the prior value shall be read only to determine the value
    > to be stored. 70)"
    >
    > So my question is, how do they derive undefined behaviour from "a[i++]
    > = i;" ?
    >
    > With, a[i++] = i; this is one expression and there is only one
    > sequence point here, ';'.
    > 'i' has its value modified only once and that is in the subscript
    > operator to designate which object the value of 'i', on the right side
    > of the assignment operator, will be stored at.
    >
    > But, I am guessing I am missing something here. So if anyone could
    > enlighten me it would be much appreciated :)


    It's the "furthermore" part that bites you here.

    The `i' on the right-hand side retrieves the value stored
    in the variable `i', correct? And is this retrieval for the
    purpose of determining what new value to store into `i'? No,
    it is not: the value retrieved is intended to be stored somewhere
    in the `a' array (but, because of U.B., there's no telling what
    might actually happen). So the right-hand-side use of `i' falls
    afoul of the "furthermore," and you've got trouble.

    Why the strange restriction? Because the Standard allows
    the side-effect of incrementing `i' to occur *anywhere* between
    the sequence point prior to this statement and the sequence
    point at the end. It might be the very first thing that happens,
    it might be the very last, it might even happen in parallel with
    other activities. That being the case, there's just no way to
    say what value the right-hand-side evaluation of `i' should
    produce, or even whether it *can* produce a meaningful value
    (think of 32-bit `long' on an 8-bit machine, where the operation
    of storing the new value might take several cycles).

    Of course, this "fuzziness" about the value doesn't extend
    to the `i++' on the left-hand side, if used in isolation. This
    sub-expression is required to yield the old value of `i', but
    the compiler can indulge in whatever sleight-of-hand it feels
    like to get this to occur. For example, it might rewrite the
    sub-expression as `(a - 1)[++i]' if that leads to smaller or
    faster code. There's just no telling when (between one sequence
    point and the next) the incrementation side-effect will become
    "visible" to the world at large.

    > Also, what is the difference between unspecified behaviour and
    > undefined behaviour? The standard attempts to make a distinction
    > between the two in Annex J but my dictionary gives the same definition
    > for "unspecified" and "undefined" so I fail to see how they can be
    > used to describe certain things as though they were different.


    The Standard uses these words (and others) in a restricted
    and specialized sense because it needs more precision than is
    afforded by ordinary English. Other fields of discourse also
    use ordinary words in specialized ways -- for example, a "field"
    means rather different things to farmers, mathematicians, and
    footballers. In Humpty Dumpty's phrase, "When I use a word, it
    means exactly what I wan it to mean-- neither more nor less. It's
    a question of who's to be master, that's all."

    The Standard gives its particular definitions of these terms
    in sections 3.4.3 and 3.4.4, and you're welcome to ponder them
    there. Informally,

    - For "unspecified" behavior, the Standard enumerates all
    the permissible behaviors but doesn't say which of them
    might actually occur. You know you'll get either A or
    B or C, but not which -- and you might not get the same
    one next time, either. However, you won't get X.

    - For "undefined" behavior, the Standard specifies nothing
    at all. You cannot assume the result will be A, B, or C;
    anything at all could happen: you could get X, or Y, or
    the program could halt, or chocolate pudding could ooze
    from your keyboard -- or, of course, you could get A.

    Nothing prevents a particular implementation from specifying
    what the Standard leaves unspecified or defining what the Standard
    leaves undefined. A particular implementation might specify that
    all operands are evaluated left-to-right, which would make the
    behavior of `a[i++] = i' perfectly well-defined -- but only for
    that implementation, of course. Another might actually define
    `a[i++] = i' as causing demons to fly from your nose -- and much
    as I might admire their technical expertise, I have absolutely
    no desire to meet the people responsible for that outcome ...

    --
    Eric Sosman, Jul 23, 2003
    #2
    1. Advertising

  3. j

    Default User Guest

    j wrote:
    >
    > In a footnote in the c99 standard the following is labeled as
    > undefined:
    >
    > a[i++] = i;


    Please review the FAQ list:

    http://www.eskimo.com/~scs/C-faq/top.html


    > Also, what is the difference between unspecified behaviour and
    > undefined behaviour? The standard attempts to make a distinction
    > between the two in Annex J but my dictionary gives the same definition
    > for "unspecified" and "undefined" so I fail to see how they can be
    > used to describe certain things as though they were different.


    And again, see the FAQ.




    Brian Rodenborn
    Default User, Jul 23, 2003
    #3
  4. j

    Mike Wahler Guest

    Shill <> wrote in message
    news:bfn533$1uvp$...
    > > Another might actually define
    > > `a[i++] = i' as causing demons to fly from your nose -- and much
    > > as I might admire their technical expertise, I have absolutely
    > > no desire to meet the people responsible for that outcome ...

    >
    > I've read the demon-from-nose bit several times in this group.
    >
    > Pray tell, which compiler might pull off such an engineering feat?
    > If Bill Gates has really made a pact with the Devil, then perhaps VC
    > is our closest bet?


    I don't know about Bill, but Mother Nature has achieved
    this long ago. Ask any allergy sufferer. :)

    -Mike
    Mike Wahler, Jul 24, 2003
    #4
  5. On Wed, 23 Jul 2003, Eric Sosman wrote:

    > j wrote:
    >> Furthermore, the prior value shall be read only to determine the value
    >> to be stored. 70)"

    >
    > It's the "furthermore" part that bites you here.
    >
    > The `i' on the right-hand side retrieves the value stored
    > in the variable `i', correct? And is this retrieval for the
    > purpose of determining what new value to store into `i'? No,


    A perverse interpretation would even say that a = i++ has
    undefined behavior, because the prior value of i is accessed to
    determine *two* values to be stored into i and a respectively,
    without an intervening sequence point.

    Tak-Shing
    Tak-Shing Chan, Jul 24, 2003
    #5
    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. Dave Theese

    Sequence points

    Dave Theese, Sep 3, 2003, in forum: C++
    Replies:
    2
    Views:
    335
    Karl Heinz Buchegger
    Sep 3, 2003
  2. Timothy Madden

    Does C++ have sequence points ?

    Timothy Madden, Sep 20, 2004, in forum: C++
    Replies:
    4
    Views:
    405
    Peter van Merkerk
    Sep 21, 2004
  3. akarl

    Knowing your sequence points

    akarl, Aug 11, 2005, in forum: C Programming
    Replies:
    7
    Views:
    387
    Jack Klein
    Aug 12, 2005
  4. Question about sequence points

    , Aug 4, 2006, in forum: C Programming
    Replies:
    3
    Views:
    279
    Clark S. Cox III
    Aug 12, 2006
  5. Question about sequence points 2

    , Aug 4, 2006, in forum: C Programming
    Replies:
    1
    Views:
    266
Loading...

Share This Page