rationale for eliding modifications to string constants

[Ian Lance Taylor]

Godmar Back <godmar@gmail.com> writes:

> this may be a FAQ - in my class today when discussing how gcc
> generates code for x86, I was stumped when I showed an example of how
> gcc handles attempts to modify (read-only) string literals/constants.
> (I'm sending this to gcc rather than gcc-help because I'm asking for a
> design rationale - I believe I understand the semantics of string
> constants in C. If in appropriate, I'm happy to resend there.)
>
> Specifically, I was surprised to see that gcc 4.1.2, when invoked with
> -O, simply elided the offending statement s[0] = 'H' in the example
> below.
>
> int
> main()
> {
>     char * s = (char *)"hello";     // read-only
>     printf("%s\n", s);
>     s[0] = 'H';    // gcc -O elides this
>     printf("%s\n", s);
>     return 0;
> }
>
> Could someone briefly provide justification/rationale for this decision?
>
> Is the rationale simply that since "the behavior of a program that
> attempts to modify a string constant is undefined" (K&R) you felt
> justified in silently discarding it (rather than letting it proceed or
> cause a runtime error if the string literal is mapped in a read-only
> section of the address space?)
>
> I note that even though the compiler knows it is taking advantage of a
> rule that allows it to produce code that contains undefined behavior,
> there appears to be no warning option to alert the user. Notably, gcc
> -Wall -Wwrite-string is silent for the above program.

I think this is simply a bug.  It doesn't happen with current gcc.  With
gcc 4.4.3 the assignment is being eliminated because it is considered to
be dead code.  

I agree that it is an error for gcc to simply eliminate this assignment
with no warning.

Ian