home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / std / c / 2993 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.4 KB
  1. Path: sparky!uunet!littlei!hfglobe!chnews!sedona!bhoughto
  2. From: bhoughto@sedona.intel.com (Blair P. Houghton)
  3. Newsgroups: comp.std.c
  4. Subject: Re: on "use", and the lvalue-ness of string literals
  5. Message-ID: <1dk4d8INNe29@chnews.intel.com>
  6. Date: 8 Nov 92 22:30:00 GMT
  7. References: <27143@dog.ee.lbl.gov> <1992Nov2.200406.18152@ichips.intel.com> <18277@ksr.com>
  8. Organization: Intel Corp., Chandler, Arizona
  9. Lines: 54
  10. NNTP-Posting-Host: alfalfa.intel.com
  11.  
  12. In article <18277@ksr.com> jfw@ksr.com (John F. Woods) writes:
  13. >If you cannot deduce that "foo" has array type from "The multibyte character
  14. >sequence is used to initialize an array of static storage duration and length
  15. >just sufficient to contain the sequence", then I suggest you quietly put your
  16. >keyboard down and go and lie down until the urge to program passes.
  17.  
  18. What I deduce from that is that the "multibyte character
  19. sequence" is not itself an array but an indicator of the
  20. initial values of an actual array.  The sentence says
  21. nothing about the type of the source of the characters,
  22. it gives rather that of the destination.
  23.  
  24. And the nap was nice, thanks.
  25.  
  26. >The only time a string literal does not become an anonymous array is when it
  27.  
  28. "Does not become?"  Not "is not?"  You contradict yourself.
  29.  
  30. Your eyelids are growing heavy.
  31.  
  32. >is used as an initializer (read "Initialization 3.5.7").  In all other cases
  33. >it is an array and has array type.  Therefore, when it appears in an lvalue
  34. >context, it is not a modifiable lvalue (because lvalues of array type are
  35. >not modifiable (see 3.2.2.1 Lvalues and Function Designators)),
  36.  
  37. It is not a modifiable lvalue because the standard explicitly
  38. forbids attempts to modify it.
  39.  
  40. You are getting sleepy, very sleeeeeepy.
  41.  
  42. >and therefore
  43. >"foo" = "bar"; violates the Constraint in section 3.3.16 that "An assignment
  44. >operator shall have a modifiable lvalue as its left operand", an therefore
  45. >a compiler *must* issue a diagnostic.  The statement about modifying string
  46. >literals doesn't enter into it.
  47.  
  48. The cookies of the bull are many and near.  This is only
  49. one of a number greater than one of reasons that this
  50. assignment is bogus.  I would not attempt to tell a compiler
  51. writer which reason to deduce first; it could upset his
  52. syntax tree.
  53.  
  54. You are aSLEEP!
  55.  
  56. >>E.g.,
  57. >>    "foo"[2] = 'g';
  58. >>results in undefined behavior.
  59. >
  60. >But no diagnostic is required in this case, because no Constraint is violated.
  61.  
  62. When I snap my fingers, you will awake.
  63.  
  64.                 --Blair
  65.                   "Is that a TAMBOURINE I see behind you?"
  66.