This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Assignment operator - summary
Andreas Schwab writes:
> If you pass a volatile pointer to strcpy you move outside the realms of
> the standard. That's what is called undefined behaviour.
OK, to see if I have the proper gasp of the issue, I try
to summarise all problems related to the assignment/volatile
business.
- The assignment operator's value is the value that can be read back
from the LHS after the assignment. In conventional memory it happens
to be identical to the value written to the LHS. It is just as right,
because some people who learnt C from the K&R books live in the false
belief that the value of an assignment is actually the value that's
written to the LHS. (Let's call them RHS believers.)
- The compiler has the ANSI C Standard guaranteed right to re-read the
LHS or to use the value that it wrote to the LHS, even if the LHS is
volatile. It thus demolishes the difference between the LHS believers
and the RHS believers because neither of them can predict what the
compiler will do.
- When the compiler decides to re-fetch the LHS and the location of
the LHS itself is volatile, it is up to the compiler to decide
whether it re-calculates the location to fetch from or uses the
location it did the write to. A C programmer's life should be
challenging and full of surprises.
- Although the standard does not guarantee it, thou shall have faith
in thy Compiler Writers that in the case of var = expr; they will
only generate a single write to var and in the case of temp = var;
they will generate a single read from var, would var be volatile.
Let us all rejoyce !
- As a consequence, those who are qualified to use volatile must write
all their code with constantly fetching all their volatile objects
to temporaries in conventional memory, processing the memory then
writing the results back to the volatile locations. No construct other
than <var> = <expr>; or <temp> = <var>; should be used on volatile
<var> objects.
- No C lib function can be used with any operands that are not in
conventional memory. If you need the functionality in an environment
that can support non-conventional memory, you should re-implement
the standard C library either in assembly, or, based on the faith
above, in C but using only simple assignments to access the volatile
objects.
- This is a Good Thing and anyone attempting to dictate a predictable
compiler behaviour with regards to the value of an assignment with
volatile LHS should be enrolled into a six-year COBOL course in a
boarding school.
Do I see it right ?
Regards,
Zoltan