unsigned long int uint32_t to unsigned char and back

MicahCarrick · 05-25-2008, 03:25 PM

I have an application in which there is an array of ID's as uint32_t. I have to pass this data through a couple functions which have a struct of unsigned char available to pass through the data.

I'm worried about how to properly do this so that it doesn't cause any problems on other platforms. The data is ONLY going to be manipulated as uint32_t*... it's just being passed around as unsigned char*.

Code:

typedef struct
{
  unsigned char *data;
  int length;
} SomeData;

void some_function_requiring_struct (SomeData *data)
{
  uint32_t *numbers = (uint32_t*)data->data;

  /* it's safe to manipulate numbers now... right? */
}

/* say we're in some function */

int len;
uint32_t *numbers;
len = some_function_populating_uint32_data (&numbers);

/* allocate struct */

data->data = (unsigned char*)data;
data->len = len;

some_function_requiring_struct (data);

Is this okay?

fantas · 05-26-2008, 08:08 AM

You're going to have endianness troubles by this approach as the byteorder can differ between platforms, and the conversion from the byte array to the integer array could fail.

There are functions like e.g. the ntoh*/hton* family

http://www.beej.us/guide/bgnet/outpu.../htonsman.html

Under the hood they just do a simple byteswapping if necessary, or nothing at all if no conversion is needed.

neonsignal · 08-02-2009, 01:39 AM

The high-endian/low-endian will only be an issue if the data is being transferred to another machine. So for example, if any network code is involved, or permanent data files, then yes, you do need to serialize the data rather than just use casting.

Arrays are packed in C, so you shouldn't have any packing issues. This would become an issue if you were using structs for the data.

You can sometimes get alignment issues when converting pointers (though not in your example), particularly when casting pointers to char.

If you really have to do something like this, I'd suggest using void pointers rather than char pointers so that it is clear that the data type has been lost.

And if there is any possibility of using C++ (even if it is just a subset), there are nicer ways to do this that don't involve casting. Using C++ doesn't mean changing all the code to an object oriented model.

Code like your example indicates one of several things: (1) use of legacy library functions which cannot be changed (so they need to have a wrapper around them); (2) data which is going to be serialized (so it should be done in a platform independent way); or (3) trying to achieve object inheritance in a non-object based language (use pointers to implement inheritance, or move to C++).