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

["pvanvugt at axys dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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