home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / std / c / 2980 < prev    next >
Encoding:
Text File  |  1992-11-08  |  5.6 KB  |  122 lines

  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!haven.umd.edu!decuac!pa.dec.com!jrdzzz.jrd.dec.com!jit345.bad.jit.dec.com!diamond
  3. From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
  4. Subject: New controversy Re: on "use", and the lvalue-ness of string literals
  5. Message-ID: <BxADzK.DLs@jrd.dec.com>
  6. Sender: usenet@jrd.dec.com (USENET News System)
  7. Nntp-Posting-Host: jit345
  8. Reply-To: diamond@jit.dec.com (Norman Diamond)
  9. Organization: Digital Equipment Corporation Japan , Tokyo
  10. References: <1992Nov2.162310.10094@ichips.intel.com> <18106@ksr.com>
  11. Date: Fri, 6 Nov 1992 08:52:32 GMT
  12. Lines: 108
  13.  
  14. In article <1992Nov2.162310.10094@ichips.intel.com> bhoughto@sedona.intel.com (Blair P. Houghton) writes:
  15. >I'm sure Norman will be able to comment
  16.  
  17. Yeah, now that your original article finally arrived here, I can figure out
  18. what everyone's been talking about.
  19.  
  20. >(having apparently nothing else to do in The Land of the Rebooting Sun)...
  21. s/Sun/Digital/
  22. s/Rebooting/[adjective deleted; for reason see preceding substitution]/
  23.  
  24. >Standard's use of the verb "to use" in the context of value contexts.
  25. >I'm trying to develop a good definition, and it's come down to a few
  26. >expression forms.  The important thing to remember is that it's the
  27. >value, not the identifier or the location, that is being "used."
  28. >    if ( foo ) ...;        /* uses `foo' */
  29. >    foo;            /* does not use `foo' */
  30. >    x = foo;        /* uses `foo' */
  31. >    foo = x;        /* does not use `foo' */
  32.  
  33. 2.1.2.3, page 8 lines 31 to 32:  "Accessing a volatile object, modifying
  34. an object, modifying a file, or calling a function that does any of those
  35. operations are all side effects."  OK, should "to use" a value mean
  36. "to access" the underlying object?  Nope; maybe for volatiles, but not
  37. necessarily others.  "To modify" the object?  Even less likely.
  38.  
  39. 2.1.2.3, page 8 line 36:  "In the abstract machine, all expressions are
  40. evaluated as specified by the semantics."  OK, should "to use" a value
  41. mean "to evaluate" the underlying expression?  Tough question.  Let's
  42. go SEMANTICS hunting.  But first...
  43.  
  44. 3.3, page 39 lines 2 to 4:  "An expression is a sequence of operators
  45. and operands that specifies computation of a value, or that designates
  46. an object or a function, or that generates side effects, or that performs
  47. a combination thereof."  OK, if an lvalue designates an object, then it
  48. meets this definition of expression (so far), and we can't guess if it
  49. also specifies computation of a value or not.
  50.  
  51. 3.3.1, page 40 lines 9 to 10 (SEMANTICS):  "An identifier is a primary
  52. expression, provided it has been declared as designating an object (in
  53. which case it is an lvalue) or a function (in which case it is a function
  54. designator)."  Hmm.  Does this mean that "foo;" does not get evaluated
  55. at all?  In fact I think so, because in "foo = x;" foo is a primary
  56. expression which does not get evaluated at all.
  57.  
  58. OK, I think I would guess that "to use" a value probably means
  59. "to evaluate" the underlying expression.
  60.  
  61. So I would have to say:
  62.     if ( foo ) ...;        /* uses `foo', though maybe invisibly[*] */
  63.     foo;            /* does not use `foo' */
  64.     x = foo;        /* uses `foo', though maybe invisibly[*] */
  65.     foo = x;        /* does not use `foo' */
  66. [* Unless foo is volatile, the access might be optimized out.]
  67.  
  68. In other words, I agree with your analysis.
  69.  
  70. But notice another unasked question that is answered by our analysis:
  71.     foo;            /* DOES NOT ACCESS `foo' EVEN IF VOLATILE */
  72. Now this one will probably be controversial.
  73. ****************************************************************************
  74.  
  75. >I'd say it was merely a matter of whether a side-effect depends on the value,
  76. >but `if ( foo ) /* empty */;' does not have any side effects, but definitely
  77. >does use the value of `foo'.  (Remember, "issues of optimization are irrel-
  78. >evant," so the null statement WILL be "executed" in the "abstract machine.")
  79.  
  80. Furthermore 3.6.4, page 78 lines 8 to 9 (SEMANTICS) demand the value of the
  81. controlling expression (though the access might be optimized out).
  82.  
  83. In article <18106@ksr.com> jfw@ksr.com (John F. Woods) writes:
  84. <the expression statement ["foo;"] accesses the object named by the
  85. <identifier "foo" and then discards the value of that object.
  86.  
  87. (Though the access might be optimized out.)  In the abstract machine, there
  88. seems to be a funny kind of access, that doesn't compute a value and doesn't
  89. modify a value.  "foo" does not get evaluated here.
  90.  
  91. <One would think that if "foo" were declared as "volatile", the object
  92. <designated by "foo" here *must* be accessed in a running program.
  93.  
  94. I agree.  But what kind of access?  Neither fetch nor store but...
  95.  
  96. <3.5.3:  "What constitutes an access to an object that has volatile-
  97. <qualified type is implementation-defined."
  98.  
  99. Yup.
  100.  
  101. <Perhaps, then, an implementation has the license to define that
  102. <    foo;
  103. <does not access the object referred to by foo, and/or that
  104. <    foo = x;
  105. <does, though in the first case I *think* that's stretching the license too far.
  106.  
  107. Close.  The implementation can define that the funny kind of access is a
  108. no-op, and it's very unclear if that's stretching a license.  After all,
  109. there was no evaluation.  In the second case, a modify access is pretty
  110. well required (whatever the implementation defines for modify access).
  111.  
  112. <Remember that a strictly conforming program cannot use "volatile"; it is not
  113. <a guarantee of portability, it is a "portable" way to beg for mercy :-).
  114.  
  115. I don't think so.  A strictly conforming program can use "volatile" on some
  116. objects, such as auto variables (important after a longjmp() or maybe signal
  117. handling) or other stuff that is in the program's name space.
  118. --
  119. Norman Diamond       diamond@jit081.enet.dec.com
  120. If this were the company's opinion, I wouldn't be allowed to post it.
  121. "It's been a lovely recession."
  122.