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

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

[jackie.rosen at hushmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #12 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ideasman42 at gmail dot com

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 71202 has been marked as a duplicate of this bug. ***

[Bug c/23087] Misleading warning, "... differ in signedness" with the character types

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW
            Summary|Misleading warning, "...    |Misleading warning, "...
                   |differ in signedness"       |differ in signedness" with
                   |                            |the character types

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

[manu at gcc dot gnu dot org]

------- Comment #11 from manu at gcc dot gnu dot org  2008-03-31 11:03 -------
Actually as a user I would find clearer a warning such:

warning: initialization of 'signed char *' from incompatible pointer type 'char
*'

so CONFIRMED.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
   Last reconfirmed|2006-01-08 05:22:34         |2008-03-31 11:03:55
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[kst at mib dot org]

------- Comment #10 from kst at mib dot org  2008-03-30 21:49 -------
(In reply to comment #9)
> >I'd expect the warning to be muted in one of the calls, depending on
> -f{un}signed-char.
>
> No, char is a seperate type from signed char and unsigned char so they are
> always incompatiable when it comes to pointers to them.
>
> Closing as invalid.

Yes, they're incompatible -- but that's not what the warning says.

I'm now using gcc 4.1.3.  (Note that the warning doesn't appear without
"-pedantic".)  Here's the current behavior:
========================================
% cat tmp.c
void foo(void)
{
    signed char   *ps = "signed?";
    unsigned char *pu = "unsigned?";
}
% gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% gcc -c -pedantic tmp.c
tmp.c: In function `foo':
tmp.c:3: warning: pointer targets in initialization differ in signedness
tmp.c:4: warning: pointer targets in initialization differ in signedness
========================================

On my system plain char is signed, so for the initialization of ps,
the pointer targets *don't* differ in signedness.  A warning is
necessary; the warning that's currently printed is incorrect.

Here's what it should do:
========================================
[...]
% gcc -c -pedantic -c tmp.c
tmp.c: In function `foo':
tmp.c:3: warning: initialization from incompatible pointer type
tmp.c:4: warning: initialization from incompatible pointer type
========================================


-- 

kst at mib dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2008-03-30 20:42 -------
>I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.

No, char is a seperate type from signed char and unsigned char so they are
always incompatiable when it comes to pointers to them.

Closing as invalid.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[axel at zankasoftware dot com]

------- Comment #8 from axel at zankasoftware dot com  2006-01-16 17:14 -------
There's also the following issue, which seem related.

$ cat test.c
void nil_uch(unsigned char *uch) {
    *uch = 0;
}

void nil_sch(signed char *sch) {
    *sch = 0;
}

int main(void) {
    char ch = 0;

    nil_uch(&ch);
    nil_sch(&ch);

    return 0;
}

$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -o test test.c
test.c: In function 'main':
test.c:14: warning: pointer targets in passing argument 1 of 'nil_uch' differ
in signedness
test.c:15: warning: pointer targets in passing argument 1 of 'nil_sch' differ
in signedness

I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.


-- 

axel at zankasoftware dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |axel at zankasoftware dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #7 from ebotcazou at gcc dot gnu dot org  2005-10-09 17:47 -------
But it's platform-independent.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
  GCC build triplet|sparc-sun-solaris2.9        |*-*-*
   GCC host triplet|sparc-sun-solaris2.9        |*-*-*
 GCC target triplet|sparc-sun-solaris2.9        |*-*-*
   Last reconfirmed|0000-00-00 00:00:00         |2005-10-09 17:47:04
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[christian dot joensson at gmail dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christian dot joensson at
                   |                            |gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[kst at mib dot org]

------- Additional Comments From kst at mib dot org  2005-07-27 19:34 -------
I misused the term "compatible" above (and I think the standard itself
is sometimes a bit loose about the term). 

All references are to the C99 standard.  I think the C90 rules are the
same or very similar.

6.7.8p11:
    
    The initializer for a scalar shall be a single expression,
    optionally enclosed in braces. The initial value of the object
    is that of the expression (after conversion); the same type
    constraints and conversions as for simple assignment apply, 
    taking the type of the scalar to be the unqualified version of
    its declared type.

6.5.16.1p1 (Simple assignment):

    One of the following shall hold:
    [...]
    -- both operands are pointers to qualified or unqualified versions
       of compatible types, and the type pointed to by the left has 
       all the qualifiers of the type pointed to by the right;

6.7.5.1p2:

    For two pointer types to be compatible, both shall be identically 
    qualified and both shall be pointers to compatible types.
    
6.2.5p14:

    The type char, the signed and unsigned integer types, and the 
    floating types are collectively called the basic types. Even if
    the implementation defines two or more basic types to have the
    same representation, they are nevertheless different types. (34)

6.2.5p15:

    The three types char, signed char, and unsigned char are 
    collectively called the _character types_. The implementation shall
    define char to have the same range, representation, and behavior
    as either signed char or unsigned char. (35)
  
Footnote 35:

    CHAR_MIN, defined in <limits.h>, will have one of the values 
    0 or SCHAR_MIN, and this can be used to distinguish the two
    options. Irrespective of the choice made, char is a separate type
    from the other two and is not compatible with either.
    
For an initialization of a char object, there's an implicit conversion,
even though types char and signed char are not compatible.

    signed char sc = 'x';
    char c = sc;     /* implicit conversion */
    
There is no implicit conversion for pointer types other than void*:

    signed char *psc = &sc;
    char *pc = psc;   /* illegal, incompatible types */


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[schlie at comcast dot net]

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

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

[kst at mib dot org]

------- Additional Comments From kst at mib dot org  2005-07-27 01:54 -------
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.
(As it is, it's merely dangerous, causing undiagnosed undefined
behavior if func attempts to modify the string.)

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.

The correct warning message should be
    "initialization from incompatible pointer type",
the same message produced for the initialization of lptr in
the following:

void bar(void)
{
    int i = 42;
    long l = i;         /* ok, implicit conversion */
    int *iptr = &i;
    long *lptr = iptr;  /* incompatible types */
}

even though int and long happen to have the same representation
on the system I'm using, just as char and signed char happen
to have the same representation.

The initializations of ps and pu in foo() are invalid,
but this has nothing to do with signedness or constness;
it's just because the types are incompatible.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-07-26 23:58 -------
(In reply to comment #2)
> String literals in C are char*, not const char*, though writing to a
> string literal invokes undefined behavior.  But that's not the point.

Actually as string literals are defined as specifying an array of character constants,
a "const char *" type seems most appropriate, which is why a write to a string literal
is undefined.

But agree that GCC should not generate a warning that the types differ in signness
when initializing a signed or unsigned char * with a string literal, as the types are
defined as being compatible; but should generate a warning that a "const char *" is
being assigned to a non-const "char *".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[kst at mib dot org]

------- Additional Comments From kst at mib dot org  2005-07-26 21:07 -------
String literals in C are char*, not const char*, though writing to a
string literal invokes undefined behavior.  But that's not the point.

Assuming plain char is signed, the warning
    "pointer targets in initialization differ in signedness"
for
    signed char   *ps = "signed?";
is misleading because the pointer targets don't differ in signedness.
They do differ in type, so a warning is appropriate, but not that warning.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-26 20:03 -------
I don't think the warning is misleading as strings are only ever "const char*"

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087