------- Additional Comments From schlie at comcast dot net 2005-05-16 02:44 ------- (In reply to comment #5) > Subject: Re: static_cast falsely allows const to be cast away > | > Yup, string literal should have type 'const char *'. > | > | I believe 'static const char []' would seem most correct? > > "static" is not part of the type. The ty[e of a string literal is > "const char[N]", N being its sizeof. There is no if no but. > Similar rule for wide string literal.
Then maybe GCC needs to broaden it's view of what information needs to be considered a type qualifier at least internally; as a storage specification can certainly restrict an object's permissible use and access, as such should be recorded and maintained as a qualifier for all objects, and pointers/references. A literal string is not simply a 'const char [N]' object, as a literal value may not be specified as a target of an assignment, directly or indirectly though a pointer cast to a non-const object reference, unlike as a plain old 'const' objects may be. Therefore possibly GCC needs to internally (and possibly optionally externally) introduce a 'literal' type qualifier, which is stronger than 'const', which may not be cast away, or be disregarded when a so qualified pointer is passed as an argument to, or returned from a function call. As although C/C++ languages don't define a 'literal' type/storage qualifier 'key-word', they certainly do specify restricted semantics for literal data use/access. Which today GCC tries to deal with by wrapping in constructors, and/or attempting to use some un-coordinated combination of 'const" and/or TREE_READONLY object or reference attributes; where a 'literal' type qualifier would seem likely both simpler and more consistent overall? (where previously I had mistakenly equated "static const" == "literal") -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
