[Q] UB query

Discussion in 'C Programming' started by Simon P Simonson, Dec 26, 2009.

  1. In the following code,

    1 main()
    2 {
    3 auto a;
    4 volatile b;
    5 (void) a;
    6 (void) b;
    7 }

    is line 5 an undefined behavior? (I would say NO)

    is line 6 an undefined behavior? (I would say YES)

    Merry Xmas
    SPS
     
    Simon P Simonson, Dec 26, 2009
    #1
    1. Advertising

  2. Simon P Simonson <> writes:
    > In the following code,
    >
    > 1 main()
    > 2 {
    > 3 auto a;
    > 4 volatile b;
    > 5 (void) a;
    > 6 (void) b;
    > 7 }
    >
    > is line 5 an undefined behavior? (I would say NO)
    >
    > is line 6 an undefined behavior? (I would say YES)


    First off, the code is written in an extremely archaic style; it's
    not even legal in C99. In older versions of C, you could omit the
    type on a declaration and it would default to int. There's no good
    reason to do that.

    int main(void)
    {
    int a;
    volatile int b;
    (void) a; /* line 5 */
    (void) b; /* line 6 */
    return 0;
    }

    I'd say yes to both. It's possible for type int to have trap
    representations. If it does, and if ``a'' happens to hold a trap
    representation, then the behavior of an attempt to access the value of
    ``a'' is undefined.

    --
    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 26, 2009
    #2
    1. Advertising

  3. On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
    <> wrote:

    >In the following code,
    >
    > 1 main()
    > 2 {
    > 3 auto a;
    > 4 volatile b;
    > 5 (void) a;
    > 6 (void) b;
    > 7 }
    >
    >is line 5 an undefined behavior? (I would say NO)
    >
    >is line 6 an undefined behavior? (I would say YES)


    An uninitialized variable without static duration has an indeterminate
    value. Any attempt to evaluate such a value leads to undefined
    behavior. The fact that you discard the result of the evaluation is
    irrelevant. Both statements invoke undefined behavior.

    --
    Remove del for email
     
    Barry Schwarz, Dec 26, 2009
    #3
  4. Simon P Simonson

    Nobody Guest

    On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:

    > In the following code,
    >
    > 1 main()
    > 2 {
    > 3 auto a;


    What's with the "auto" qualifier?

    In over 20 years of C programming, I haven't even seen it once in
    real-world code.

    It's primary purpose seems to be to trip up programmers who don't play
    language lawyer as a hobby. I.e.:

    Step 1: write:

    int auto = 0; /* do "it" automatically */

    Step 2: spend 5 minutes wondering why the compiler's complaining about
    "syntax error before '=' token".

    Step 3: discover that changing it to:

    int xauto = 0; /* do "it" automatically */

    eliminates the error message.

    Step 4: ask the resident language lawyer about "auto".

    Step 5: end up spending the rest of the afternoon discussing punched
    cards, EBCDIC, and JCL.
     
    Nobody, Dec 29, 2009
    #4
  5. Barry Schwarz wrote:

    > On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
    > <> wrote:
    >
    >>In the following code,
    >>
    >> 1 main()
    >> 2 {
    >> 3 auto a;
    >> 4 volatile b;
    >> 5 (void) a;
    >> 6 (void) b;
    >> 7 }
    >>
    >>is line 5 an undefined behavior? (I would say NO)
    >>
    >>is line 6 an undefined behavior? (I would say YES)

    >
    > An uninitialized variable without static duration has an indeterminate
    > value. Any attempt to evaluate such a value leads to undefined
    > behavior. The fact that you discard the result of the evaluation is
    > irrelevant. Both statements invoke undefined behavior.


    Are you sure about this analysis?

    Code 1 <<EOF
    auto a;
    (void) a;
    EOF

    Code 2 <<EOF
    auto a;
    EOF

    By the "as if" rule, these two code extracts are equivalent, and most
    (all?) compilers will not generate any code for Code 1 following the "as
    if" rule.
     
    Simon P Simonson, Dec 30, 2009
    #5
  6. Nobody wrote:
    > On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:
    >
    >> In the following code,
    >>
    >> 1 main()
    >> 2 {
    >> 3 auto a;

    >
    > What's with the "auto" qualifier?
    >
    > In over 20 years of C programming, I haven't even seen it once in
    > real-world code.
    >
    > It's primary purpose seems to be to trip up programmers who don't play
    > language lawyer as a hobby. I.e.:
    >
    > Step 1: write:
    >
    > int auto = 0; /* do "it" automatically */
    >
    > Step 2: spend 5 minutes wondering why the compiler's complaining about
    > "syntax error before '=' token".
    >
    > Step 3: discover that changing it to:
    >
    > int xauto = 0; /* do "it" automatically */
    >
    > eliminates the error message.
    >
    > Step 4: ask the resident language lawyer about "auto".
    >
    > Step 5: end up spending the rest of the afternoon discussing punched
    > cards, EBCDIC, and JCL.


    Obviously I used auto to emphasize and draw attention to the contrast
    between volatile and non-volatile variables that was at the heart of my
    question. Normally I don't use the auto qualifier in my code.
     
    Simon P Simonson, Dec 30, 2009
    #6
  7. Simon P Simonson wrote:

    > Barry Schwarz wrote:
    >
    >> On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
    >> <> wrote:
    >>
    >>>In the following code,
    >>>
    >>> 1 main()
    >>> 2 {
    >>> 3 auto a;
    >>> 4 volatile b;
    >>> 5 (void) a;
    >>> 6 (void) b;
    >>> 7 }
    >>>
    >>>is line 5 an undefined behavior? (I would say NO)
    >>>
    >>>is line 6 an undefined behavior? (I would say YES)

    >>
    >> An uninitialized variable without static duration has an indeterminate
    >> value. Any attempt to evaluate such a value leads to undefined
    >> behavior. The fact that you discard the result of the evaluation is
    >> irrelevant. Both statements invoke undefined behavior.

    >
    > Are you sure about this analysis?
    >
    > Code 1 <<EOF
    > auto a;
    > (void) a;
    > EOF
    >
    > Code 2 <<EOF
    > auto a;
    > EOF
    >
    > By the "as if" rule, these two code extracts are equivalent, and most
    > (all?) compilers will not generate any code for Code 1 following the "as
    > if" rule.


    Actually this raises the interesting question: What code should a
    compiler generated for Code 3?

    Code 3 <<EOF
    volatile a;
    (void) a;
    EOF
     
    Simon P Simonson, Dec 30, 2009
    #7
  8. Simon P Simonson wrote:

    > Nobody wrote:
    >> On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:
    >>
    >>> In the following code,
    >>>
    >>> 1 main()
    >>> 2 {
    >>> 3 auto a;

    >>
    >> What's with the "auto" qualifier?
    >>
    >> In over 20 years of C programming, I haven't even seen it once in
    >> real-world code.
    >>
    >> It's primary purpose seems to be to trip up programmers who don't play
    >> language lawyer as a hobby. I.e.:
    >>
    >> Step 1: write:
    >>
    >> int auto = 0; /* do "it" automatically */
    >>
    >> Step 2: spend 5 minutes wondering why the compiler's complaining about
    >> "syntax error before '=' token".
    >>
    >> Step 3: discover that changing it to:
    >>
    >> int xauto = 0; /* do "it" automatically */
    >>
    >> eliminates the error message.
    >>
    >> Step 4: ask the resident language lawyer about "auto".
    >>
    >> Step 5: end up spending the rest of the afternoon discussing punched
    >> cards, EBCDIC, and JCL.

    >
    > Obviously I used auto to emphasize and draw attention to the contrast
    > between volatile and non-volatile variables that was at the heart of my
    > question. Normally I don't use the auto qualifier in my code.


    This also raise the iteresting question: Is it a good idea to use
    slightly obscure language features in your code (e.g. sizeof a++) to
    force future maintainers of your code to be up to scratch on the dark
    corners of the language?
     
    Simon P Simonson, Dec 30, 2009
    #8
  9. Simon P Simonson

    Tom St Denis Guest

    Re: UB query

    On Dec 30, 8:33 am, Simon P Simonson <> wrote:
    > Simon P Simonson wrote:
    > > Nobody wrote:
    > >> On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:

    >
    > >>> In the following code,

    >
    > >>>      1     main()
    > >>>      2     {
    > >>>      3       auto a;

    >
    > >> What's with the "auto" qualifier?

    >
    > >> In over 20 years of C programming, I haven't even seen it once in
    > >> real-world code.

    >
    > >> It's primary purpose seems to be to trip up programmers who don't play
    > >> language lawyer as a hobby. I.e.:

    >
    > >> Step 1: write:

    >
    > >>        int auto = 0;   /* do "it" automatically */

    >
    > >> Step 2: spend 5 minutes wondering why the compiler's complaining about
    > >> "syntax error before '=' token".

    >
    > >> Step 3: discover that changing it to:

    >
    > >>        int xauto = 0;  /* do "it" automatically */

    >
    > >> eliminates the error message.

    >
    > >> Step 4: ask the resident language lawyer about "auto".

    >
    > >> Step 5: end up spending the rest of the afternoon discussing punched
    > >> cards, EBCDIC, and JCL.

    >
    > > Obviously I used auto to emphasize and draw attention to the contrast
    > > between volatile and non-volatile variables that was at the heart of my
    > > question. Normally I don't use the auto qualifier in my code.

    >
    > This also raise the iteresting question: Is it a good idea to use
    > slightly obscure language features in your code (e.g. sizeof a++) to
    > force future maintainers of your code to be up to scratch on the dark
    > corners of the language?


    No, if I caught a developer here writing things like "sizeof a++" I'd
    make them clean it up [or I'd do it myself and commit the fix].

    Hard to read code is not the sign of genius. It's the sign of
    lazyness. Using extra parenthesis for example may mean you're not
    100% sure of order of precedence [bad] but it also makes the code a
    lot easier to read [good].

    Tom
     
    Tom St Denis, Dec 30, 2009
    #9
  10. Simon P Simonson

    Nick Guest

    Simon P Simonson <> writes:

    > This also raise the iteresting question: Is it a good idea to use
    > slightly obscure language features in your code (e.g. sizeof a++) to
    > force future maintainers of your code to be up to scratch on the dark
    > corners of the language?


    Only if it's the "best" way to do things. Even if the future maintainer
    is you, there's no point in making things complicated just for the fun
    of it.

    I feel that quite strongly about a number of the "is this undefined
    behaviour" threads we get. If after 3 days people are still arguing
    about it, just don't use it!
    --
    Online waterways route planner | http://canalplan.eu
    Plan trips, see photos, check facilities | http://canalplan.org.uk
     
    Nick, Dec 30, 2009
    #10
  11. Simon P Simonson <> writes:

    > Simon P Simonson wrote:
    >
    >> Barry Schwarz wrote:
    >>
    >>> On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
    >>> <> wrote:
    >>>
    >>>>In the following code,
    >>>>
    >>>> 1 main()
    >>>> 2 {
    >>>> 3 auto a;
    >>>> 4 volatile b;
    >>>> 5 (void) a;
    >>>> 6 (void) b;
    >>>> 7 }
    >>>>
    >>>>is line 5 an undefined behavior? (I would say NO)
    >>>>
    >>>>is line 6 an undefined behavior? (I would say YES)
    >>>
    >>> An uninitialized variable without static duration has an indeterminate
    >>> value. Any attempt to evaluate such a value leads to undefined
    >>> behavior. The fact that you discard the result of the evaluation is
    >>> irrelevant. Both statements invoke undefined behavior.

    >>
    >> Are you sure about this analysis?


    Barry is correct from the point of view of portable code, but an
    indeterminate value is always either a valid (but unknown) value of
    the type in question or it is a trap representation. On a system
    whose int type has no trap representations, the effect of evaluating
    an indeterminate value is not undefined (in the C sense of the word).
    Of course, what value you get is not specified so the effect is
    "undefined" in the ordinary sense of the word.

    >> Code 1 <<EOF
    >> auto a;
    >> (void) a;
    >> EOF
    >>
    >> Code 2 <<EOF
    >> auto a;
    >> EOF
    >>
    >> By the "as if" rule, these two code extracts are equivalent, and most
    >> (all?) compilers will not generate any code for Code 1 following the "as
    >> if" rule.


    The "as if" rule can't be used to make undefined code defined. On a
    system with an int type that has trap reps., a compiler can replace
    Code 1 with anything it likes. If int has no trap reps., then Code 1
    is defined, and the compiler can replace it with Code 2 because it is
    equivalent.

    > Actually this raises the interesting question: What code should a
    > compiler generated for Code 3?
    >
    > Code 3 <<EOF
    > volatile a;
    > (void) a;
    > EOF


    Pass. On the face of it, it must generate code to access a, but there
    may be ways in which it can prove that this is not required.

    --
    Ben.
     
    Ben Bacarisse, Dec 30, 2009
    #11
  12. Simon P Simonson <> writes:
    > Barry Schwarz wrote:
    >
    >> On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
    >> <> wrote:
    >>
    >>>In the following code,
    >>>
    >>> 1 main()
    >>> 2 {
    >>> 3 auto a;
    >>> 4 volatile b;
    >>> 5 (void) a;
    >>> 6 (void) b;
    >>> 7 }
    >>>
    >>>is line 5 an undefined behavior? (I would say NO)
    >>>
    >>>is line 6 an undefined behavior? (I would say YES)

    >>
    >> An uninitialized variable without static duration has an indeterminate
    >> value. Any attempt to evaluate such a value leads to undefined
    >> behavior. The fact that you discard the result of the evaluation is
    >> irrelevant. Both statements invoke undefined behavior.

    >
    > Are you sure about this analysis?
    >
    > Code 1 <<EOF
    > auto a;
    > (void) a;
    > EOF
    >
    > Code 2 <<EOF
    > auto a;
    > EOF
    >
    > By the "as if" rule, these two code extracts are equivalent, and most
    > (all?) compilers will not generate any code for Code 1 following the "as
    > if" rule.


    The "as if" rule doesn't say they're equivalent. It says that
    an implementation is allowed to eliminate the evaluation of "a",
    transforming Code 1 to the equivalent of Code 2. It's not *required*
    to eliminate it.

    If "a" happens to contain a trap representation, and the compiler
    doesn't optimize away the evaluation, then the program could crash.
    (Accessing a trap representation doesn't necessarily cause a crash,
    but that's one of the infinitely many possible consequences of
    undefined behavior.)

    A compiler is allowed to *assume* that no undefined behavior occurs,
    and generate code based on that assumption. This is most commonly
    shows up in optimization, but a compiler could emit extra checks.
    For example, it might generate code that checks whether any variables
    are used without being initialized, and that terminates the program
    with an error message if the check fails. (Create a flag for
    each declared variable. Set it to 1 when the variable has a value
    assigned to it. Check the flag whenever the variable is accessed.
    Or there might be hardware support.)

    --
    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, 2009
    #12
  13. Simon P Simonson <> writes:
    [...]
    > Obviously I used auto to emphasize and draw attention to the contrast
    > between volatile and non-volatile variables that was at the heart of my
    > question. Normally I don't use the auto qualifier in my code.


    Here's the code again:

    1 main()
    2 {
    3 auto a;
    4 volatile b;
    5 (void) a;
    6 (void) b;
    7 }

    (Incidentally, posting code with line numbers makes it more difficult
    for the rest of us to copy-and-paste it and try it ourselves. If you
    want to refer to a line by number, add a "/* line 5 */ comment.)

    "auto" is a storage-class specifier; "volatile" is a type qualifier.
    Both "a" and "b" have the same storage class. If you wanted to be
    painfully explicit, you could have written:

    auto int a;
    volatile auto int b;

    This:

    int a;
    volatile int b;

    would have been clearer and would have made your point better.
    Omitting the type, and letting it default to int, is considered
    poor style in C90, and isn't even allowed in C99.

    --
    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, 2009
    #13
  14. Ben Bacarisse wrote:

    > Simon P Simonson <> writes:


    >>> Code 1 <<EOF
    >>> auto a;
    >>> (void) a;
    >>> EOF
    >>>
    >>> Code 2 <<EOF
    >>> auto a;
    >>> EOF
    >>>
    >>> By the "as if" rule, these two code extracts are equivalent, and most
    >>> (all?) compilers will not generate any code for Code 1 following the
    >>> "as if" rule.

    >
    > The "as if" rule can't be used to make undefined code defined. On a
    > system with an int type that has trap reps., a compiler can replace Code
    > 1 with anything it likes. If int has no trap reps., then Code 1 is
    > defined, and the compiler can replace it with Code 2 because it is
    > equivalent.
    >
    >> Actually this raises the interesting question: What code should a
    >> compiler generated for Code 3?
    >>
    >> Code 3 <<EOF
    >> volatile a;
    >> (void) a;
    >> EOF

    >
    > Pass. On the face of it, it must generate code to access a, but there
    > may be ways in which it can prove that this is not required.


    OK, but what does it mean to access a? If a is stored in a memory
    location (possibly memory mapped hardware) is it enough to load a into a
    register? What if a is already in cache?
     
    Simon P Simonson, Dec 30, 2009
    #14
  15. On Wed, 30 Dec 2009 13:26:30 +0000 (UTC), Simon P Simonson
    <> wrote:

    >Barry Schwarz wrote:
    >
    >> On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
    >> <> wrote:
    >>
    >>>In the following code,
    >>>
    >>> 1 main()
    >>> 2 {
    >>> 3 auto a;
    >>> 4 volatile b;
    >>> 5 (void) a;
    >>> 6 (void) b;
    >>> 7 }
    >>>
    >>>is line 5 an undefined behavior? (I would say NO)
    >>>
    >>>is line 6 an undefined behavior? (I would say YES)

    >>
    >> An uninitialized variable without static duration has an indeterminate
    >> value. Any attempt to evaluate such a value leads to undefined
    >> behavior. The fact that you discard the result of the evaluation is
    >> irrelevant. Both statements invoke undefined behavior.

    >
    >Are you sure about this analysis?
    >
    >Code 1 <<EOF
    >auto a;
    >(void) a;
    >EOF
    >
    >Code 2 <<EOF
    >auto a;
    >EOF
    >
    >By the "as if" rule, these two code extracts are equivalent, and most
    >(all?) compilers will not generate any code for Code 1 following the "as
    >if" rule.


    You didn't ask if the generated code would be well behaved on most
    systems. What about turning ALL optimization off.

    You used the standard specific term "undefined behavior" so I assumed
    you wanted to know what the standard specified.

    I guess I could have been a bit more precise and said the behavior is
    undefined at the point the value is evaluated.

    --
    Remove del for email
     
    Barry Schwarz, Dec 30, 2009
    #15
  16. Simon P Simonson

    Flash Gordon Guest

    Simon P Simonson wrote:
    > Ben Bacarisse wrote:
    >
    >> Simon P Simonson <> writes:


    <snip>

    >>> Actually this raises the interesting question: What code should a
    >>> compiler generated for Code 3?
    >>>
    >>> Code 3 <<EOF
    >>> volatile a;
    >>> (void) a;
    >>> EOF

    >> Pass. On the face of it, it must generate code to access a, but there
    >> may be ways in which it can prove that this is not required.

    >
    > OK, but what does it mean to access a?


    That is implementation defined...

    > If a is stored in a memory
    > location (possibly memory mapped hardware) is it enough to load a into a
    > register? What if a is already in cache?


    The documentation for the implementation should tell you what it does,
    since implementation defined means it has to be documented. In most
    implementations it will do something sensible, and if you need to do
    more than just use volatile it will tell you what, but that is a matter
    of quality rather than requirement.
    --
    Flash Gordon
     
    Flash Gordon, Dec 30, 2009
    #16
  17. Simon P Simonson <> writes:
    > Ben Bacarisse wrote:
    >> Simon P Simonson <> writes:

    [...]
    >>> Actually this raises the interesting question: What code should a
    >>> compiler generated for Code 3?
    >>>
    >>> Code 3 <<EOF
    >>> volatile a;
    >>> (void) a;
    >>> EOF

    >>
    >> Pass. On the face of it, it must generate code to access a, but there
    >> may be ways in which it can prove that this is not required.

    >
    > OK, but what does it mean to access a? If a is stored in a memory
    > location (possibly memory mapped hardware) is it enough to load a into a
    > register? What if a is already in cache?


    Here's what the standard says (C99 6.7.3p6):

    An object that has volatile-qualified type may be modified
    in ways unknown to the implementation or have other unknown
    side effects. Therefore any expression referring to such an
    object shall be evaluated strictly according to the rules of
    the abstract machine, as described in 5.1.2.3. Furthermore,
    at every sequence point the value last stored in the object
    shall agree with that prescribed by the abstract machine, except
    as modified by the unknown factors mentioned previously. What
    constitutes an access to an object that has volatile-qualified
    type is implementation-defined.

    with a footnote:

    A volatile declaration may be used to describe an object
    corresponding to a memory-mapped input/output port or an object
    accessed by an asynchronously interrupting function. Actions
    on objects so declared shall not be ‘‘optimized out’’
    by an implementation or reordered except as permitted by the
    rules for evaluating expressions.

    On the other hand, if you just apply "volatile" to a local variable,
    the compiler can reasonably know that there's no magic going on behind
    the scenes. It's not clear whether the compiler is permitted to take
    advantage of this knowledge; I'd say it probably isn't.

    --
    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, 2009
    #17
  18. Simon P Simonson

    Tim Rentsch Guest

    Ben Bacarisse <> writes:

    > Simon P Simonson <> writes:
    >
    >> Simon P Simonson wrote:
    >>
    >>> Barry Schwarz wrote:
    >>>
    >>>> On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
    >>>> <> wrote:
    >>>>
    >>>>>In the following code,
    >>>>>
    >>>>> 1 main()
    >>>>> 2 {
    >>>>> 3 auto a;
    >>>>> 4 volatile b;
    >>>>> 5 (void) a;
    >>>>> 6 (void) b;
    >>>>> 7 }
    >>>>>
    >>>>>is line 5 an undefined behavior? (I would say NO)
    >>>>>
    >>>>>is line 6 an undefined behavior? (I would say YES)
    >>>>
    >>>> An uninitialized variable without static duration has an indeterminate
    >>>> value. Any attempt to evaluate such a value leads to undefined
    >>>> behavior. The fact that you discard the result of the evaluation is
    >>>> irrelevant. Both statements invoke undefined behavior.
    >>>
    >>> Are you sure about this analysis?

    >
    > Barry is correct from the point of view of portable code, but an
    > indeterminate value is always either a valid (but unknown) value of
    > the type in question or it is a trap representation. On a system
    > whose int type has no trap representations, the effect of evaluating
    > an indeterminate value is not undefined (in the C sense of the word).
    > Of course, what value you get is not specified so the effect is
    > "undefined" in the ordinary sense of the word.


    This was covered (IIRC) in one of the DR's. I believe the
    behavior is undefined even if the type in question has no
    trap representations, eg, even (unsigned char) can be
    undefined behavior. That doesn't hold (again IIRC) for
    variables whose address has been taken with &, and I'm
    not sure if a variable declared 'volatile' is different.
     
    Tim Rentsch, Jan 13, 2010
    #18
  19. Simon P Simonson

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Simon P Simonson <> writes:
    >> Ben Bacarisse wrote:
    >>> Simon P Simonson <> writes:

    > [...]
    >>>> Actually this raises the interesting question: What code should a
    >>>> compiler generated for Code 3?
    >>>>
    >>>> Code 3 <<EOF
    >>>> volatile a;
    >>>> (void) a;
    >>>> EOF
    >>>
    >>> Pass. On the face of it, it must generate code to access a, but there
    >>> may be ways in which it can prove that this is not required.

    >>
    >> OK, but what does it mean to access a? If a is stored in a memory
    >> location (possibly memory mapped hardware) is it enough to load a into a
    >> register? What if a is already in cache?

    >
    > Here's what the standard says (C99 6.7.3p6):
    >
    > An object that has volatile-qualified type may be modified
    > in ways unknown to the implementation or have other unknown
    > side effects. Therefore any expression referring to such an
    > object shall be evaluated strictly according to the rules of
    > the abstract machine, as described in 5.1.2.3. Furthermore,
    > at every sequence point the value last stored in the object
    > shall agree with that prescribed by the abstract machine, except
    > as modified by the unknown factors mentioned previously. What
    > constitutes an access to an object that has volatile-qualified
    > type is implementation-defined.
    >
    > with a footnote:
    >
    > A volatile declaration may be used to describe an object
    > corresponding to a memory-mapped input/output port or an object
    > accessed by an asynchronously interrupting function. Actions
    > on objects so declared shall not be ''optimized out''
    > by an implementation or reordered except as permitted by the
    > rules for evaluating expressions.
    >
    > On the other hand, if you just apply "volatile" to a local variable,
    > the compiler can reasonably know that there's no magic going on behind
    > the scenes. It's not clear whether the compiler is permitted to take
    > advantage of this knowledge; I'd say it probably isn't.


    The whole point of volatile is that the compiler does NOT know
    and must not assume that it does, even for local variables.
     
    Tim Rentsch, Jan 13, 2010
    #19
  20. Tim Rentsch <> writes:

    > Ben Bacarisse <> writes:

    <snip?
    >> Barry is correct from the point of view of portable code, but an
    >> indeterminate value is always either a valid (but unknown) value of
    >> the type in question or it is a trap representation. On a system
    >> whose int type has no trap representations, the effect of evaluating
    >> an indeterminate value is not undefined (in the C sense of the word).
    >> Of course, what value you get is not specified so the effect is
    >> "undefined" in the ordinary sense of the word.

    >
    > This was covered (IIRC) in one of the DR's. I believe the
    > behavior is undefined even if the type in question has no
    > trap representations, eg, even (unsigned char) can be
    > undefined behavior.


    Do you have a reference? A DR that modifies what seems to be the
    clear wording of standard, it usually ends with an edit to the wording
    which should be reflected in the drafts. I don't understand the
    process that well, so I may have got this wrong. The text of the DR
    would help.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Jan 13, 2010
    #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. Learner
    Replies:
    1
    Views:
    1,027
    Marina Levit [MVP]
    Jan 30, 2006
  2. Anonymous
    Replies:
    0
    Views:
    1,550
    Anonymous
    Oct 13, 2005
  3. David Gordon

    xpath query query

    David Gordon, May 18, 2005, in forum: XML
    Replies:
    2
    Views:
    833
    David Gordon
    May 18, 2005
  4. Eric Nelson
    Replies:
    5
    Views:
    1,578
    Alexey Smirnov
    Feb 4, 2009
  5. Jon F.

    CAML Query: Multiple Query Fields Issue

    Jon F., May 12, 2004, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    774
    Jon F.
    May 12, 2004
Loading...

Share This Page