endianness

I had a discussion this morning with a colleague regarding the correctness of a "coding trick" to detect endianness. The trick was: bool is_big_endian() { union { int i; char c[sizeof(int)]; } foo; foo.i = 1; return (foo.c[0] == 1); } To me, it seems that this usage of an union is incorrect because setting one member of the union and reading another is not well-defined. But I have to admit that this is just a feeling and I lack actual proofs to strengthen my point. Is this trick correct ? Who is right here ? Your code is not portable. It might work on some compilers or it might not. You are

I need to convert a short value from the host byte order to little endian. If the target was big endian, I could use the htons() function, but alas - it's not. I guess I could do: swap(htons(val)) But this could potentially cause the bytes to be swapped twice, rendering the result correct but giving me a performance penalty which is not alright in my case. Something like the following: unsigned short swaps( unsigned short val) { return ((val & 0xff) << 8) | ((val & 0xff00) >> 8); } /* host to little endian */ #define PLATFORM_IS_BIG_ENDIAN 1 #if PLATFORM_IS_LITTLE_ENDIAN unsigned short htoles(

I ran the following program on little-endian [LE] machine [Linux, Intel processor]. I am unable to explain the 3 outputs in below code snippet. Since machine is LE, the value of a is stored as 0x78563412 . When printing, it is displaying its actual value. Since its an LE machine, I expect ntohl() to be a no-op and display 0x78563412 , which it is doing. However, I expect 0x12345678 for 2nd print statement containing htonl() . Can someone please help me understand why they are same? int main() { int a = 0x12345678; printf("Original - 0x%x\n", (a)); printf("Network - 0x%x\n", htonl(a)); printf(

I'm devising a file format for my application, and I'd obviously like for it to work on both big-endian and little-endian systems. I've already found working solutions for managing integral types using htonl and ntohl , but I'm a bit stuck when trying to do the same with float and double values. Given the nature of how floating-point representations work, I would assume that the standard byte-order functions won't work on these values. Likewise, I'm not even entirely sure if endianness in the traditional sense is what governs the byte order of these types. All I need is consistency. A way to

In the code below, why do X and Y take on different values than what I would think intuitively? If the bytes 0-7 are written to the buffer, shouldn't the resulting long have bytes in the same order? It's like it's reading the long values in reverse order. x 0x0706050403020100 long y 0x0706050403020100 long z 0x0001020304050607 long MemoryStream ms = new MemoryStream(); byte[] buffer = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 }; ms.Write(buffer, 0, buffer.Length); ms.Flush(); ms.Position = 0; BinaryReader reader = new BinaryReader(ms); long x = reader.ReadInt64(); long y =

I have a system where a remote agent sends serialized structures (from an embedded C system) for me to read and store via IP/UDP. In some cases I need to send back the same structure types. I thought I had a nice setup using Marshal.PtrToStructure (receive) and Marshal.StructureToPtr (send). However, a small gotcha is that the network big endian integers need to be converted to my x86 little endian format to be used locally. When I'm sending them off again, big endian is the way to go. Here are the functions in question: private static T BytesToStruct<T>(ref byte[] rawData) where T: struct { T