------- Additional Comments From schlie at comcast dot net 2005-07-27 16:22
-------
(In reply to comment #4)
> Oh, I agree completely that making string literals const
> (as they are in C++) would make more sense. The reason they
> aren't defined that way in C is that by the time "const" was
> added to the language, there was too much code that would be
> broken by the change. For example, given
> void func(char *s);
> the call
> func("hello");
> would be a constraint violation if string literals were const.
- yes, and would have been at least been made visable if a
warning that a "const char *" was being assigned to a "char *"
were arguably properly generated when passed as an argument.
(although I may be blind, I can find reference to the elements
of a string literal being const char's, I can't find any specifying
albeit this, a string literal is defined as a "char *", as opposed
to more properly a "const char *"?)
> But all this is beside the point. I get the same warning
> messages with this:
>
> void foo(void)
> {
> const signed char *ps = "signed?";
> const unsigned char *pu = "unsigned?";
> }
>
> Plain char, unsigned char, and signed char are all compatible,
> in the sense that you can use a value of any of the three
> types to initialize an object of any of the three types
> (possibly with an implicit conversion).
>
> But because they are all distinct types, pointers to those types
> are distinct and incompatible types.
- understood, but as the types pointed to are "compatible" is seem
like a mistake to interpret thier respective pointers as being otherwise.
(as their referenced object's values may be assigned freely to each other,
so it would seem that arguably pointers to them should be treated similarly.
Which would also be consistent with the standard's apparent aliasing guidline:
6.3 Expressions
[#7] An object shall have its stored value accessed only by
an lvalue expression that has one of the following types:59
- a type compatible with the effective type of the
object,
- a qualified version of a type compatible with the
effective type of the object,
- a type that is the signed or unsigned type
corresponding to the effective type of the object,
- a type that is the signed or unsigned type
corresponding to a qualified version of the effective
__________
59. The intent of this list is to specify those
circumstances in which an object may or may not be
aliased.
Which seems to imply stongly that compatible types which only
differ in qualification and/or signness should be considred as being
potentially aliased by such coresponding pointers, as they reference
strinctly compaible types?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
