Typecasting on littleendian and bigendian

[kux]

hello,

I have the following problem
I have an unsigned long variable, but it is designed to hold values within 0 .. 100 ( I know an unsigned char would have been enough, but i have to use an unsigned long ).
I have to write that value in a file on a single byte.

if i do fwrite(&unsignedlongvar, 1, 1, file ) it will write the octet on the lowest adress of the variable. If the system is little endian this is ok because that is where the value I am intrested in is, but if the system would be big endian the value I am intrested in would be at the highest adress and the fwrite would write the lowest octet. How do you suggest solving the porting problem? Is there any standard function to test the endianess of the system?

thx in advance

[tesuji]

what about solving little/big endian problem by doing appropriate typecast before writing to file?

[vijayan121]

> Is there any standard function to test the endianess of the system?

inline bool little_endian()
{
  union
  {
    long i ;
    char c[ sizeof(long) ] ;
  };
  i = 1 ;
  return c[0] == 1 ;
}

[Salem]

> what about solving little/big endian problem by doing appropriate typecast before writing to file?
Because endian can't be fixed with a simple cast.
You have to write code to rearrange the bytes into the correct order.

> Is there any standard function to test the endianess of the system?
Not only is this non-portable (it assumes far too much about internal representations), it also assumes that there are only two endian systems (there's at least 3).
http://en.wikipedia.org/wiki/Endianness

[Duoas]

If you know your target value will fit in a smaller integer, you really don't need to worry about endianness. Do as tesuji suggests and let the compiler do the appropriate movement:

fputc( unsignedlongvar, file );  // bits 8..31 are lost!

Don't use fwrite() for size-specific I/O. The C and C++ standards require a char to be one byte (eight bits), but there is no requirement on internal representation. So it is possible to find some funky system/compiler that stores them in word values... and if the endianness isn't strictly little-endian, then using fwrite() won't work.

Hope this helps.

[tesuji]

Hi Salem,

> what about solving little/big endian problem by doing appropriate typecast before writing to file?
Because endian can't be fixed with a simple cast.
You have to write code to rearrange the bytes into the correct order.

> Is there any standard function to test the endianess of the system?
Not only is this non-portable (it assumes far too much about internal representations), it also assumes that there are only two endian systems (there's at least 3).
http://en.wikipedia.org/wiki/Endianness

This is a completely wrong conclusion :) (maybe you didn't stick to the very original question)

No matter hardware is based on little-, mid- or big-endian, typecast from longer to shorter representation (and vice versa), for example from long double to float, will be correctly carried out. Apart from general loss of precision due to shorting the mantissa, serious problem may occur if the receiving exponent area is too short, what would lead to overflow. But this problems aren't caused by how the byte sequence is physically ordered in memory. Fairly occasionally one will get confronted with the endian problem, for example if one does TCP/IP programming, where data structures often still stick to big-endian tradition from Digital Equipment era.

Oh yes, no, there is no flag telling you "hello, I am little endian", you have to know it!

btw, if you know what endian your data is coded, swapping the bytes to get another endian coding is a very plain task.

krs,
tesu

[Salem]

> Is there any standard function to test the endianess of the system?
This was an original question - what are you smoking?