Does cast between signed and unsigned int maintain exact bit pattern of variable in memory?

c casting int unsigned htonl
Flash picture Flash · Oct 21, 2013 · Viewed 27.1k times · Source

I want to pass a 32-bit signed integer x through a socket. In order that the receiver knows which byte order to expect, I am calling htonl(x) before sending. htonl expects a uint32_t though and I want to be sure of what happens when I cast my int32_t to a uint32_t.

int32_t x = something;
uint32_t u = (uint32_t) x;

Is it always the case that the bytes in x and u each will be exactly the same? What about casting back:

uint32_t u = something;
int32_t x = (int32_t) u;

I realise that negative values cast to large unsigned values but that doesn't matter since I'm just casting back on the other end. However if the cast messes with the actual bytes then I can't be sure casting back will return the same value.

Answer

Christoph picture Christoph · Oct 21, 2013

In general, casting in C is specified in terms of values, not bit patterns - the former will be preserved (if possible), but the latter not necessarily so. In case of two's complement representations without padding - which is mandatory for the fixed-with integer types - this distinction does not matter and the cast will indeed be a noop.

But even if the conversion from signed to unsigned would have changed the bit pattern, converting it back again would have restored the original value - with the caveat that out-of-range unsigned to signed conversion is implementation-defined and may raise a signal on overflow.

For full portability (which will probably be overkill), you'll need to use type punning instead of conversion. This can be done in one of two ways:

Via pointer casts, ie

uint32_t u = *(uint32_t*)&x;

which you should be careful with as it may violate effective typing rules (but is fine for signed/unsigned variants of integer types) or via unions, ie

uint32_t u = ((union { int32_t i; uint32_t u; }){ .i = x }).u;

which can also be used to eg convert from double to uint64_t, which you may not do with pointer casts if you want to avoid undefined behaviour.

Related questions

How to cast or convert an unsigned int to int in C?

My apologies if the question seems weird. I'm debugging my code and this seems to be the problem, but I'm not sure. Thanks!

Read More
C: cast int to size_t

What is the proper way to convert/cast an int to a size_t in C99 on both 32bit and 64bit linux platforms? Example: int hash(void * key) { //... } int main (int argc, char * argv[]) { size_t size = 10; void * items[size]; //... …

Read More
Cast int to pointer - why cast to long first? (as in p = (void*) 42; )

In the GLib documentation, there is a chapter on type conversion macros. In the discussion on converting an int to a void* pointer it says (emphasis mine): Naively, you might try this, but it's incorrect: gpointer p; int i; p = (…

Read More