Godmar Back <god...@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
