> My own experience with analyzing runtime bugs that I have found and
> fixed in code which mis-used string constants shows that if the compiler
> implements read-only and/or shared storage for string constants (as GCC
> does by default) then the only way to catch these bugs at compile time
> is to use "const char *" as the default implied type for string
> constants (except, it seems, when they are used as array initializers).

Just be glad you aren't using the old IBM (IIRC) system which had the
constants 0, 1, 2 at 'well known' addresses.  This system ran FORTRAN
and all arguments are passed by reference.  If a routine accidentally
changed a (supposedly) constant 1 that was passed to it, then the
value of 1 changed for the entire OS.

> I'm not a compiler guru, but I do know from reading compiler generated
> assembly code that an average C compiler implementation will take the
> string literal used in an initializer statement and put it in the data
> segment and then it will (if the variable is global) store the address
> of that string constant in the variable being initialized (i.e. at the
> data segment address for that variable).
> 
> If the compiler and linker implement a .rodata segment and uses it for
> string literal then in fact that string literal will be stored in
> read-only storage and it won't matter how the pointer variable being
> initialized is declared because it will point at read-only storage.

IIRC --writable-strings causes gcc to put strings in the .data instead
of .rodata.  I'm not at all sure it even changes the (impiled) type
of the string itself.


	David

-- 
David Laight: david@l8s.co.uk