Re: Removing -frwitable-strings

[Jamie Lokier <jamie at shareable dot org>]

Mark Mitchell wrote:
> > It would seem that the front end would need to generate a static
> > char[] array for each literal string, and use its address as the value
> > of the literal string expression.  If that were done, the back end could
> > eliminate its support for -fwritable-strings.
> 
> Yes.  
> 
> But, even that will not work because there are places in the front ends
> that expect string constants to be STRING_CSTs.
> 
> It's possible that the conversion you suggest could be done at tree->rtl
> conversion time.  That is the approach I would try if I had to implement
> it.

I'm not sure that would work.  STRING_CST seems to suggest it's a
_constant_ and some tree-level or tree generation optimisers might
think they can constant-fold things like dereferencing characters in
the string or strlen().  Or at least, they ought to be able to assume
that without checking the -fwritable-strings flag.

Those optimisation aren't valid when strings are writable, so it makes
sense to represent writable strings at the tree level and at the front
end, for _expressions_ only, as char[] arrays instead.

(Strings still need to be strings for concatenation and string
initialises in C; otherwise, static char[] arrays are a fine
representation).

Is there anything wrong with this C source level transformation when
"string" is an expression, as opposed to structure initialiser?
   
       "string"

becomes

       /* Magically outside function scope. */
       static char x[] = "string";
       /* Back to your regular function scope. */
       x


({ static char x[] = "string"; x; }) doesn't work because of sizeof(),
and ((char[]) { "string" }) doesn't work because it's not static.  But
that's just C language difficulties; the C frontend should have no
difficulty creating a static anonymous array of the appropriate kind.

-- Jamie