0

Here is the program I used:

int hex = 0x23456789;
char * val = &hex;
printf("%p\n",hex);
printf("%p %p %p %p\n",*val,*(val+1),*(val+2),*(val+3));

Here is my output:

0x23456789
0xffffff89 0x67 0x45 0x23

I am working on a 64 bit CPU with a 64 bit OS. This shows my machine is little endian. Why is the first byte 0xffffff89? Why the ff's?

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
Bruce
  • 33,927
  • 76
  • 174
  • 262

5 Answers5

5

Firstly, you should be using %x since those aren't pointers.

The %x specifiers expect an integer. Because you are passing in a value of type 'char', which is a signed type, the value is being converted to an integer and being sign extended. http://en.wikipedia.org/wiki/Sign_extension

That essentially means that it takes the most significant bit and uses it for all the higher bits. So 0x89 => 0b10001001 , which has a highest bit of '1' becomes 0xFFFFFF89.

The proper solution is to specify a 'length' parameter options. You can get more info here: Printf Placeholders Essentially, between the '%' and the 'x', you can put extra parameters. 'hh' means that you are passing a char value.

int hex = 0x23456789;
char *val = (char*)&hex;

printf("%x\n",hex);
printf("%hhx %hhx %hhx %hhx\n", val[0], val[1], val[2], val[3]);
loganfsmyth
  • 156,129
  • 30
  • 331
  • 251
  • 1
    `"%p"` expects a `void *`, not an integer. Any pointer will work on most machines but to be technically correct (because of varargs) you should explicitly cast when you use it. – Chris Lutz Sep 04 '11 at 17:47
  • 1
    Also, you need to use `"%hhx"` to print an `unsigned char` value, as opposed to a full-sized `unsigned` value. – Chris Lutz Sep 04 '11 at 18:20
  • Nice! I knew 'h', but I didn't know 'hh' existed, so that's why I had the unsigned casting. I've updated my answer to include this better method. – loganfsmyth Sep 04 '11 at 18:35
3

char is a signed type, it gets promoted to int when passed as an argument. This promotion causes sign extension. 0x89 is a negative value for char, it gets thus sign-extended to 0xffffff89. This does not happen for the other values, they don't exceed CHAR_MAX, 127 or 0x7f on the most machines. You are getting confused by this behavior because you use the wrong format specifier.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

%p is asking printf to format it as an address, you are actaully passing a value (*val)

On a 64 bit machine pointer addresses are 64bit, so printf is adding the ffff to pad the fields

Community
  • 1
  • 1
Martin Beckett
  • 94,801
  • 28
  • 188
  • 263
  • Why isn't it doing it for the other values? like 0xffffff67. I used %x instead of %p and I get the same output. – Bruce Sep 04 '11 at 17:26
  • It's undefined behaviour, you are asking it to print as an a address a value that isn't an address. So it could be using the next value on the stack, or it could print pink unicorns – Martin Beckett Sep 04 '11 at 17:28
  • 2
    @Bruce: Because it's getting sign-extended. I'm betting it'll change if you declare `val` as an `unsigned char*` instead. – user786653 Sep 04 '11 at 17:38
1

As @Martin Beckett said, %p asks printf to print a pointer, which is equivalent to %#x or %#lx (the exact format depends on your OS).

This means printf expect an int or a long (again depends on OS), but you are only supplying it with char so the value is up-cast to the appropriate type.

When you cast a smaller signed number to a bigger signed number you have to do something called sign extension in order to preserve the value. In the case of 0x89 this occurs because the sign bit is set, so the upper bytes are 0xff and get printed because they are significant.

In the case of 0x67, 0x45, 0x23 sign extension does not happen because the sign bit is not set, and so the upper bytes are 0s and thus not printed.

freespace
  • 16,529
  • 4
  • 36
  • 58
1

I test the endian-ness with the condition ((char)((int)511) == (char)255). True means little, false means big.

I have tested this on a few separate systems, both little and big, using gcc with optimizations off and to max. In every test I have done I have gotten correct results.

You could put that condition in an if of your application before it needs to do endian-critical operations. If you only want to guarentee you are using the right endian-ness for your entire application, you could instead use a static assertion method such as follows:

extern char ASSERTION__LITTLE_ENDIAN[((char)((int)511) == (char)255)?1:-1];

That line in the global scope will create a compile error if the system is not little endian and will refuse to compile. If there was no error, it compiles perfectly as if that line didn't exist. I find that the error message is pretty descriptive:

error: size of array 'ASSERTION__LITTLE_ENDIAN' is negative

Now if you're paranoid of your compiler optimizing the actual check away like I am, you can do the following:

int endian;
{
    int i = 255;
    char * c = &i;
    endian = (c[0] == (char)255);
}
if(endian) // if endian is little

Which compacts nicely in to this macro:

#define isLittleEndian(e) int e; { int i = 255; char * c = &i; e = (c[0] == (char)255); }
isLittleEndian(endian);
if(endian) // if endian is little

Or if you use GCC, you can get away with:

#define isLittleEndian ({int i = 255; char * c = &i; (c[0] == (char)255);})
if(isLittleEndian) // if endian is little
jenchampagne
  • 41
  • 3