Subject: Re: xstr vs. gcc 3.3.1
To: Greywolf <firstname.lastname@example.org>
From: John Nemeth <email@example.com>
Date: 12/04/2003 04:45:16
On Feb 23, 3:36am, Greywolf wrote:
} After some courage and some digging, I finally found out what's
} breaking with SHAREDSTRINGS. It appears that xstr produces output
} which is obsolete -- or at least gcc 3.3.1 does not want to play
} well with it.
More like just plain broken.
} The other problem is that of the semantic difference between
} static char *foo = (something);
} static char bar = (something);
} The former can have either a string literal or a reference given to it as
The string literal is a const which can't be changed.
} an rvalue, while the latter is restricted to a string literal only --
In this case, the string literal is only an initialiser for the
array and can be changed.
} statements of the form (given "extern char _xstr;")
} static char bar = (&_xstr);
} are not considered valid input to gcc.
Not surprising since an array is not a pointer.
} I see the following solutions to the second problem:
} 1. Obsolete xstr. I'm not sure if this is desirable or not;
Probably not, but it does need to be taught the C language.
} 2. Update xstr to either leave the RHS of static char  alone or
} convert it to static char *;
Absolutely not! An array is not a pointer! They have different
semantics and blindly converting between them could really screw up a
} 3. Update all sources to use static char *foo instead of static char foo;
No, they have different uses.
} 4. Update all sources to use
} #ifdef __xstr__
} static char *foo
} static char foo
} = "initialiser";
No, this would horribly complicate a program.
} Questions? Comments? Where do we go from here?
The only acceptable thing is to collapse string constants, but to
leave array initialisers alone. String constants are allowed to live
in read-only storage and thus aren't allowed to be change; however, the
contents of arrays can be changed.
}-- End of excerpt from Greywolf