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