home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / std / c / 2988 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!world!ksr!jfw
  2. From: jfw@ksr.com (John F. Woods)
  3. Newsgroups: comp.std.c
  4. Subject: Re: on "use", and the lvalue-ness of string literals
  5. Message-ID: <18277@ksr.com>
  6. Date: 6 Nov 92 14:24:28 EST
  7. References: <1992Nov2.162310.10094@ichips.intel.com> <27143@dog.ee.lbl.gov> <1992Nov2.200406.18152@ichips.intel.com>
  8. Sender: news@ksr.com
  9. Lines: 37
  10.  
  11. bhoughto@sedona.intel.com (Blair P. Houghton) writes:
  12. >In article <27143@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
  13. >>In article <1992Nov2.162310.10094@ichips.intel.com> bhoughto@sedona.intel.com
  14. >>(Blair P. Houghton) writes:
  15. >>>    "A string literal is a primary expression.
  16. >>>     It is an lvalue..."
  17. >>>    "foo" = "bar";    /* Is this okay? */
  18. >>No, it is a `non-modifiable lvalue', just like an array---and in fact,
  19. >>a string literal *is* an array (type `array N of char', even though the
  20. >>actual char's may themselves be const).
  21. >The Standard says something about translation phase 7 and
  22. >adding a '\0' and initializing an array with static storage
  23. >duration.
  24. >It doesn't say directly that "foo" has array type (in the
  25. >context above),
  26.  
  27. If you cannot deduce that "foo" has array type from "The multibyte character
  28. sequence is used to initialize an array of static storage duration and length
  29. just sufficient to contain the sequence", then I suggest you quietly put your
  30. keyboard down and go and lie down until the urge to program passes.
  31.  
  32. The only time a string literal does not become an anonymous array is when it
  33. is used as an initializer (read "Initialization 3.5.7").  In all other cases
  34. it is an array and has array type.  Therefore, when it appears in an lvalue
  35. context, it is not a modifiable lvalue (because lvalues of array type are
  36. not modifiable (see 3.2.2.1 Lvalues and Function Designators)), and therefore
  37. "foo" = "bar"; violates the Constraint in section 3.3.16 that "An assignment
  38. operator shall have a modifiable lvalue as its left operand", an therefore
  39. a compiler *must* issue a diagnostic.  The statement about modifying string
  40. literals doesn't enter into it.
  41.  
  42. >E.g.,
  43. >    "foo"[2] = 'g';
  44. >results in undefined behavior.
  45.  
  46. But no diagnostic is required in this case, because no Constraint is violated.
  47.  
  48.