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