This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]