Duplicate..please ignore!

[SuzyC]

I inadvertently created two posts, nearly identical..my apologies..but no way on this board to remove either one!

Working with Hi-Tech C, I can successfully code the following lines and everything works fine:
 
static unsigned char Buf[20];
static unsigned char * bp=Buf;

//and in main() there is no problem with:
              strcpy(bp, "Hellow");

//Here's the problem: Writing code with Cypress C99 I can again code with no warnings or errors:

static unsigned char Buf[20];
static unsigned char * bp=Buf;
 
//But when I try:

strcpy(bp, "Hellow");

//I get the following warning: "passing 'unsigned char *' to  parameter of type "char*" converts to integer types of different signs"

[legacy]

//I get the following warning: "passing 'unsigned char *' to  parameter of type "*char"

try by removing "unsigned" and use just "char"


In the same context, if this thing would be gave as input to our home-made Arise-v2-HL compiler would complain of a similar error 

[SuzyC]

Thanks a million bits!

That fixed the problem!

But I don't quite understand why pointers would would be converted to integers with different sign???

Is it because C99 is C+ instead of just C ?

[brucehoult]

Thanks a million bits!

That fixed the problem!

But I don't quite understand why pointers would would be converted to integers with different sign???

Is it because C99 is C+ instead of just C ?

The pointers won't be converted to integers. They'll be converted to "pointer to char" (char being a kind of integer).

Presumably on that system "char" is the same as "signed char". That is the more usual case.

Although with -Wall I see that modern gcc complains about passing *both* "signed char*" and "unsigned char*" to an argument declared as simply "char*" !!!

[SiliconWizard]

The warning message is somewhat inept in its phrasing, but yes that just means you're passing a pointer to a different type (unsigned char) than expected (char).
As far as I can remember, a lot, if not most compilers I've run into have treated 'char' as a signed integer type in C, although it's not uncommon to find "embedded" C compilers treating 'char' as unsigned.
The signedness of 'char' is not strictly defined in the C standard, that's why you can run into both implementations and that's also probably why GCC warns you when you use signed char * instead of char *, because even though they may be the same on the given platform, they are are not in general, so the warning is not completely unreasonable IMO, it will help spotting portability issues.

The corrolary is: don't use the 'char' type if you care about signedness. It should be only used as a storage facility. For signed operations, it's preferable to cast to a signed char or unsigned char explicitely first.

Better yet if you explicitely intend on dealing with "byte"-wide integers (8-bit) is to use the standard 'int8_t' and 'uint8_t' types, and use 'char' only for C strings or individual characters of said strings.

[Siwastaja]

Although with -Wall I see that modern gcc complains about passing *both* "signed char*" and "unsigned char*" to an argument declared as simply "char*" !!!

This makes sense for producing portable code, because it's better to see the warning when compiling on any platform, than randomly on some of the platforms.