[Bug c/23087] Misleading warning, "... differ in signedness"

["schlie at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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