Conversion from unsigned to signed type safety?

Question

Is it safe to convert, say, from an unsigned char * to a signed char * (or just a char *?

Answer 1

The conversion should be safe, as all you're doing is converting from one type of character to another, which should have the same size. Just be aware of what sort of data your code is expecting when you dereference the pointer, as the numeric ranges of the two data types are different. (i.e. if your number pointed by the pointer was originally positive as unsigned, it might become a negative number once the pointer is converted to a signed char* and you dereference it.)

Answer 2

It depends on how you are going to use the pointer. You are just converting the pointer type.

Answer 3

You can safely convert an unsigned char* to a char * as the function you are calling will be expecting the behavior from a char pointer, but, if your char value goes over 127 then you will get a result that will not be what you expected, so just make certain that what you have in your unsigned array is valid for a signed array.

Answer 4

I've seen it go wrong in a few ways, converting to a signed char from an unsigned char.

One, if you're using it as an index to an array, that index could go negative.

Secondly, if inputted to a switch statement, it may result in a negative input which often is something the switch isn't expecting.

Third, it has different behavior on an arithmetic right shift

int x = ...;
char c = 128
unsigned char u = 128

c >> x;

has a different result than

u >> x;

Because the former is sign-extended and the latter isn't.

Fourth, a signed character causes underflow at a different point than an unsigned character.

So a common overflow check,

(c + x > c)

could return a different result than

(u + x > u)

Answer 5

Safe if you are dealing with only ASCII data.

Answer 6

Casting changes the type, but does not affect the bit representation. Casting from unsigned char to signed char does not change the value at all, but it affects the meaning of the value.

Here is an example:

#include <stdio.h>
int main(int args, char** argv) {

  /* example 1 */
  unsigned char a_unsigned_char = 192;
  signed char b_signed_char = b_unsigned_char;
  printf("%d, %d\n", a_signed_char, a_unsigned_char); //192, -64

  /* example 2 */
  unsigned char b_unsigned_char = 32; 
  signed char a_signed_char = a_unsigned_char;
  printf("%d, %d\n", b_signed_char, b_unsigned_char); //32, 32

  return 0;
}

In the first example, you have an unsigned char with value 192, or 110000000 in binary. After the cast to signed char, the value is still 110000000, but that happens to be the 2s-complement representation of -64. Signed values are stored in 2s-complement representation.

In the second example, our unsigned initial value (32) is less than 128, so it seems unaffected by the cast. The binary representation is 00100000, which is still 32 in 2s-complement representation.

To "safely" cast from unsigned char to signed char, ensure the value is less than 128.

Answer 7

The access is well-defined, you are allowed to access an object through a pointer to signed or unsigned type corresponding to the dynamic type of the object (3.10/15).

Additionally, signed char is guaranteed not to have any trap values and as such you can safely read through the signed char pointer no matter what the value of the original unsigned char object was.

You can, of course, expect that the values you read through one pointer will be different from the values you read through the other one.

Edit: regarding sellibitze's comment, this is what 3.9.1/1 says.

A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers.

So indeed it seems that signed char may have trap values. Nice catch!

Answer 8

I'm astonished it hasn't been mentioned yet: Boost numeric cast should do the trick - but only for the data of course.

Pointers are always pointers. By casting them to a different type, you only change the way the compiler interprets the data pointed to.