[Bug c/28912] New: Non-functional -funsigned-char: signed/unsigned mismatch is reported

[Bug c/28912] New: Non-functional -funsigned-char: signed/unsigned mismatch is reported

[gcc at brainhub dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

Given the following source:

1:   #include <stdio.h>

3:   unsigned char *p = NULL;
4:   char *s = NULL;

6:   unsigned char *p1 = "p";
7:   char *s1 = "s";

9:  int main()  {
10:    s = p;

12:    char c=255;
13:    printf("%d",c);

15:    return 0;
   }

   gcc -Wall _.c -o _ && ./_

produces:

   _.c:6: warning: pointer targets in initialization differ in signedness
   _.c: In function ‘main’:
   _.c:10: warning: pointer targets in assignment differ in signedness
   -1

   gcc -funsigned-char  -Wall _.c -o _ && ./_

produces:

   _.c:6: warning: pointer targets in initialization differ in signedness
   _.c: In function ‘main’:
   _.c:10: warning: pointer targets in assignment differ in signedness
   255

and, finally, 

   gcc  -funsigned-char  -Wno-pointer-sign -Wall _.c -o _ && ./_ /_

produces

   255

Reported issue: 
   gcc generates excessive signedness mismatch warning

Expected result:
   -funsigned-char must promote "char" to "unsigned char" and not issues the
warnings.

Known workaround:
   Use -Wno-pointer-sign. 

   However, this supporesses warnings for all types, which is rarely
acceptable. Note that the char signedness issue is typically a side effect of
Unicodization of the project from ASCII encodings to UTF-8.


-- 
           Summary: Non-functional -funsigned-char: signed/unsigned mismatch
                    is reported
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gcc at brainhub dot org
 GCC build triplet: gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) [standard
                    FC 5]
  GCC host triplet: i386-redhat-linux
GCC target triplet: Linux 2.6.16.20 #1 PREEMPT Fri Jun 9 23:10:34 PDT 2006
                    i686 i686


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-30 22:45 -------
This is not a bug as char pointers are special by the C standard.  char is a
different type from either unsigned char or signed char.  Also you should not
use -funsigned-char/-fsigned-char unless you know what you are doing because it
could change the ABI.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[pvanvugt at axys dot com]

------- Comment #2 from pvanvugt at axys dot com  2006-09-21 20:49 -------
(In reply to comment #1)
> This is not a bug as char pointers are special by the C standard.  char is a
> different type from either unsigned char or signed char.  Also you should not
> use -funsigned-char/-fsigned-char unless you know what you are doing because it
> could change the ABI.
> 

I have encountered this issue as well.  I am using the gcc 4.1.1 cross-compiler
for an embedded arm-elf target, running under cygwin.  I am using a string
function library (included with eCos) that uses char rather than signed char or
unsigned char as its string pointer data type.  I do not consider this use of
char to be very portable, as its signedness may depend on the architecture, so
I have chosen to explicitly use type unsigned char for all my string pointers
and to use the -funsigned-char compiler option to force all the chars in my
string function library to be unsigned as well.  In principle, this seems like
a very reasonable choice.  I would expect that this switch should cause char
and unsigned char to have the same sign, but, if I compile the following code
with the -funsigned-char flag:

    char char_var = 0xFF;
    char *pchar_var = &char_var;
    unsigned char *puchar_var = pchar_var;

I get "warning: pointer targets in initialization differ in signedness", and
other such warnings for the rest of my code about the targets of pointers to
chars and unsigned chars having different signs.  This is an illogical result,
unless char is neither signed or unsigned.  Finally, I can see how this might
break the ABI when linking with precompiled libraries for the target
architecture that have used a different signedness for their chars, but I don't
see how this would be a problem for me.

     Peter van Vugt (nospam_pvanvugt at axys dot com)


-- 


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-21 21:03 -------
(In reply to comment #2)
> (In reply to comment #1)
> > This is not a bug as char pointers are special by the C standard.  char is a
> > different type from either unsigned char or signed char.  Also you should not
> > use -funsigned-char/-fsigned-char unless you know what you are doing because it
> > could change the ABI.
> > 
> I have encountered this issue as well.  I am using the gcc 4.1.1 cross-compiler
> for an embedded arm-elf target, running under cygwin.  I am using a string
> function library (included with eCos) that uses char rather than signed char or
> unsigned char as its string pointer data type.  I do not consider this use of
> char to be very portable, as its signedness may depend on the architecture, so
> I have chosen to explicitly use type unsigned char for all my string pointers
> and to use the -funsigned-char compiler option to force all the chars in my
> string function library to be unsigned as well.  In principle, this seems like
> a very reasonable choice.  I would expect that this switch should cause char
> and unsigned char to have the same sign, but, if I compile the following code
> with the -funsigned-char flag:
>     char char_var = 0xFF;
>     char *pchar_var = &char_var;
>     unsigned char *puchar_var = pchar_var;

In C, char is special compared to int, etc.  It can default to either signed or
unsigned and is a different type from the explicate signed/unsigned char.

6.2.5/15 and note 35 explains that char, signed char and unsigned char are
always different types unlike int and signed int.  This does not matter on the
options you use either, they are always different types.


-- 


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[gcc at brainhub dot org]

------- Comment #4 from gcc at brainhub dot org  2006-09-21 21:19 -------
I accepts Andrew's point, but note that you will get errors, not warnings, for
identical C++ code.

The problem is exacerbate by libc prototypes such as size_t strlen(const char
*s). If you want to use libc functions, perhaps for their efficient __built_in
equivalents, all your strings will need to be char * strings or you need to use
explicit casts. Most of code today is assuming unsigned char * strings; UTF-8
strings are unsigned char * strings, for example.  

Given this inconsistency it would be nice to have new option in gcc to suppress
char-related signedness warnings. In many projects these warnings are just a
noise. 


-- 


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-09-21 21:24 -------
(In reply to comment #4)
> I accepts Andrew's point, but note that you will get errors, not warnings, for
> identical C++ code.

Right, this is still invalid code in both C and C++, just in the C front-end we
decided to warn by default instead of error out.  You can get an error with the
C front-end by doing -pednatic-errors

> The problem is exacerbate by libc prototypes such as size_t strlen(const char
> *s).

Because that is what the C (and C++) standard defines the prototypes as.

As I mentioned your code is invalid according to the C (and C++) standard
so warning is the correct thing to do.

I would think you should not care about the signedness of char really.

The agrument about UTF-8 is really bogus as you can do:
unsigned char a = *b;
where b is a pointer to char and get the correct result.


-- 


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[mf dot danger at gmail dot com]

------- Comment #6 from mf dot danger at gmail dot com  2006-09-25 18:47 -------
After consulting the oracle (In the this case ANSI X3.159-1989,) and being
unable to find any information to support the claim that char is always
different type than unsigned char or signed char, I'd like to have this bug
reopened, at least as amended by my comments below.

3.5.4.1 (Pointer Declarators) and 3.3.3.2 (Address and Indirection Operators)
the sections that deal with pointers make no mention, and 3.1.2.5 definitely
says that whether char is signed or not is implementation defined.

However, it seems to me, the discussion of what type char is is missing the one
point of the original bug.  The original bug points out that when the default
type of char is set to one of signed or unsigned, the compiler does not treat
pointers to char as if they have the same signedness as char. I'd like to at
least see that much fixed, so that if -funsigned-char is used, then references
through pointers are treated to the same warnings as direct references.

By the way, there is no 6.2 in the the C '89 spec, as far as I can tell.  Which
spec were you referencing?

Aside: char serves two distinct roles in C. While it is the character type, it
is _also_ the smallest integer type. It is the only 8 bit integer type on most
processors, and so serves the purpose of 8 bit integer arithmetic.  This turns
out to be important in cryptographic applications, among other things.


-- 


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-09-25 19:29 -------
(In reply to comment #6)
> After consulting the oracle (In the this case ANSI X3.159-1989,) and being
> unable to find any information to support the claim that char is always
> different type than unsigned char or signed char, I'd like to have this bug
> reopened, at least as amended by my comments below.

> 3.5.4.1 (Pointer Declarators) and 3.3.3.2 (Address and Indirection Operators)
> the sections that deal with pointers make no mention, and 3.1.2.5 definitely
> says that whether char is signed or not is implementation defined.

C++ in a way is clearer here that char, signed char, and unsigned char are
three distant types but C90 and C99 do say that but is not clear about it.

> However, it seems to me, the discussion of what type char is is missing the one
> point of the original bug.  The original bug points out that when the default
> type of char is set to one of signed or unsigned, the compiler does not treat
> pointers to char as if they have the same signedness as char. I'd like to at
> least see that much fixed, so that if -funsigned-char is used, then references
> through pointers are treated to the same warnings as direct references.

-funsigned-char just changes the default semantics of char and not the actual
type.

> By the way, there is no 6.2 in the the C '89 spec, as far as I can tell.  Which
> spec were you referencing?

C99.

> Aside: char serves two distinct roles in C. While it is the character type, it
> is _also_ the smallest integer type. It is the only 8 bit integer type on most
> processors, and so serves the purpose of 8 bit integer arithmetic.  This turns
> out to be important in cryptographic applications, among other things.

Again, this was orginally done this way because of K&R C.  It is also a special
integer type which means char, signed char and unsigned char three distant
types.


-- 


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

[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported

[joseph at codesourcery dot com]

------- Comment #8 from joseph at codesourcery dot com  2006-09-26 11:37 -------
Subject: Re:  Non-functional -funsigned-char: signed/unsigned
 mismatch is reported

On Mon, 25 Sep 2006, pinskia at gcc dot gnu dot org wrote:

> C++ in a way is clearer here that char, signed char, and unsigned char are
> three distant types but C90 and C99 do say that but is not clear about it.

I'd say C90 (6.1.2.5) "Even if the implementation defines two or more 
basic types to have the same representation, they are nevertheless 
different types." is perfectly clear.  In C99 the 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.

is added.


-- 


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