home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2638 < prev    next >
Encoding:
Text File  |  1992-09-15  |  1.9 KB  |  43 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!decwrl!twwells!bill
  3. From: bill@twwells.com (T. William Wells)
  4. Subject: Re: void expressions and volatile types
  5. Date: Wed, 16 Sep 1992 00:40:51 GMT
  6. Message-ID: <BunB85.Drq@twwells.com>
  7. References: <BtnI48.D9I@twwells.com> <1992Sep07.104043.19879@x.co.uk>
  8. Organization: None, Mt. Laurel, NJ
  9. Lines: 32
  10.  
  11. > Here's the mistake. The value of the expression can be obtained by
  12. > remembering the value stored into a - it is not necessary to re-fetch
  13. > it, even though a is volatile.
  14.  
  15. Wrong. The standard is quite clear: the value of the result is the
  16. *value of the left operand after the assignment*. It is *not* the
  17. value stored into the left operand. In the case of non-volatiles,
  18. this makes no difference. In the case of volatiles this *requires*
  19. an access to the variable to obtain the value.
  20.  
  21. > The storing of a value into a is a side-effect, and so takes place
  22. > sometime before the next sequence point. Any other change that takes
  23. > place to a (e.g. because it is a memory-mapped device) between the same
  24. > pair of sequence points counts as a double assignment, and is therefore
  25. > undefined, and therefore the implementation can do what it wants
  26. > (including not reading a after storing).
  27.  
  28. Wrong again. The relevant section says *stores by an expression*
  29. thus explicitly excluding stores from other sources.
  30.  
  31. So the question stands: does an assign to a volatile in the
  32. context of a void expression require an additional load to obtain
  33. the value? Or may "discard" be interpreted to mean "not obtain"?
  34. The former requires an additional load of the volatile in order
  35. to obtain the value; the second does not. At the moment, my
  36. compiler does not generate the additional load because otherwise
  37. writing device drivers would be almost impossible. But I'd really
  38. like to see an *INFORMED* opinion on this.
  39.  
  40. ---
  41. Bill                            { uunet | decwrl | telesci }!twwells!bill
  42. bill@twwells.com
  43.