🚀 go-pugleaf

bhoughto@sedona.intel.com (Blair P. Houghton) writes:
>In article <27143@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
>>In article <1992Nov2.162310.10094@ichips.intel.com> bhoughto@sedona.intel.com
>>(Blair P. Houghton) writes:
>>>	"A string literal is a primary expression.
>>>	 It is an lvalue..."
>>>    "foo" = "bar";	/* Is this okay? */
>>No, it is a `non-modifiable lvalue', just like an array---and in fact,
>>a string literal *is* an array (type `array N of char', even though the
>>actual char's may themselves be const).
>The Standard says something about translation phase 7 and
>adding a '\0' and initializing an array with static storage
>duration.
>It doesn't say directly that "foo" has array type (in the
>context above),

If you cannot deduce that "foo" has array type from "The multibyte character
sequence is used to initialize an array of static storage duration and length
just sufficient to contain the sequence", then I suggest you quietly put your
keyboard down and go and lie down until the urge to program passes.

The only time a string literal does not become an anonymous array is when it
is used as an initializer (read "Initialization 3.5.7").  In all other cases
it is an array and has array type.  Therefore, when it appears in an lvalue
context, it is not a modifiable lvalue (because lvalues of array type are
not modifiable (see 3.2.2.1 Lvalues and Function Designators)), and therefore
"foo" = "bar"; violates the Constraint in section 3.3.16 that "An assignment
operator shall have a modifiable lvalue as its left operand", an therefore
a compiler *must* issue a diagnostic.  The statement about modifying string
literals doesn't enter into it.

>E.g.,
>	"foo"[2] = 'g';
>results in undefined behavior.

But no diagnostic is required in this case, because no Constraint is violated.