Page 1 of 2
Endians
Posted: Wed Jan 23, 2013 5:09 am
by BMW
In C, integers are stored in big-endian format right?
But look at this struct, a struct which shows the format of a memory map entry.
Code: Select all
typedef struct __attribute__((__packed__))
{
uint32_t BaseL; // base address QWORD
uint32_t BaseH;
uint32_t LengthL; // length QWORD
uint32_t LengthH;
uint16_t Type; // entry Ttpe
uint16_t ACPI; // exteded
} SMAP_entry;
It gets a 64-bit integer from 2 big-endian integers stored in little-endian format?????? wtf??? how does that work???
Shouldn't the whole thing be stored in big-endian, so the BaseH should come before BaseL?
Re: Endians
Posted: Wed Jan 23, 2013 5:17 am
by thepowersgang
No. C does not define the endianess of its datatypes, the architecture does.
On most modern architectures, this is little-endian, but on the odd one (SPARC, and maybe PPC - not sure) [and in java] big endian is used.
Re: Endians
Posted: Wed Jan 23, 2013 5:43 am
by iansjack
A lot of RISC processors (Sparc, PPC, Alpha) leave the choice up to the programmer. One of the best-known examples of a big-endian computer would be the Motorola 68000 family.
Re: Endians
Posted: Wed Jan 23, 2013 9:27 am
by qw
Maybe some feature should be introduced into the C standard to determine the endianness at compile-time (or possibly run-time) for greater portability.
EDIT: This code may be of interest:
https://svn.apache.org/repos/asf/incuba ... l/endian.h
Re: Endians
Posted: Wed Jan 23, 2013 10:28 am
by iansjack
I'm not sure about that. I would say that it only matters when you are operating at such a low level that you really ought to be thinking about what you are doing. Code that depends upon how the processor stores bytes in memory probably isn't going to be portable in the first place.
Re: Endians
Posted: Wed Jan 23, 2013 10:56 am
by Antti
iansjack wrote:I would say that it only matters when you are operating at such a low level that you really ought to be thinking about what you are doing.
I disagree. It does not have to be very low level. Binary file formats etc.
Re: Endians
Posted: Wed Jan 23, 2013 11:13 am
by iansjack
If you are, as in the example that started this thread, reading two 32-bit integers from a binary file and then combing them to form a 64-bit integer then I think you need to be aware of the storage conventions of the binary file. I would say that is low-level enough for you to specify things explicitly rather than relying upon the compiler. structs need thought in this respect anyway because of packing considerations.
It's possible that I am reading the word "determine" differently from others; I took it to mean "impose" rather than "discover".
Re: Endians
Posted: Wed Jan 23, 2013 4:17 pm
by BMW
iansjack wrote:If you are, as in the example that started this thread, reading two 32-bit integers from a binary file and then combing them to form a 64-bit integer then I think you need to be aware of the storage conventions of the binary file. I would say that is low-level enough for you to specify things explicitly rather than relying upon the compiler. structs need thought in this respect anyway because of packing considerations.
It's possible that I am reading the word "determine" differently from others; I took it to mean "impose" rather than "discover".
Would this be the correct way to print the 64-bit base in the SMAP struct?
Code: Select all
PrintNumberBase16(sm[i].BaseH & 0x000000FF);
PrintNumberBase16(sm[i].BaseH >> 8 & 0x000000FF);
PrintNumberBase16(sm[i].BaseH >> 16 & 0x000000FF);
PrintNumberBase16(sm[i].BaseH >> 24);
PrintNumberBase16(sm[i].BaseL & 0x000000FF);
PrintNumberBase16(sm[i].BaseL >> 8 & 0x000000FF);
PrintNumberBase16(sm[i].BaseL >> 16 & 0x000000FF);
PrintNumberBase16(sm[i].BaseL >> 24);
Note: the PrintNumberBase16 prints one byte at a time.
Re: Endians
Posted: Wed Jan 23, 2013 5:41 pm
by Griwes
Why don't you fire up your emulator/user space test program/whatever and check it out?
By the way, this has exactly nothing to do with endianess.
Re: Endians
Posted: Wed Jan 23, 2013 8:42 pm
by BMW
How does that have nothing to do with endianness?
Is it because we are reading it as an unsigned int, so the endianness doesn't matter?? If we were reading it byte by byte, would the endianness matter then?
Re: Endians
Posted: Wed Jan 23, 2013 11:50 pm
by trinopoty
The Endian matters only when you are writing memory as a collection of bytes (int, long, etc), and reading it one byte at a time (or, at a smaller size than you used to write it). If you are reading it at the same size you used to write it, the Endian does not matter. The processor will take care of that for you.
For example:
if you write memory as int, and read it as char for short, you need to consider the Endian; but if you read it as int, you can live your life happily without considering the Endian order of the processor.
Re: Endians
Posted: Thu Jan 24, 2013 2:58 am
by bluemoon
trinopoty wrote:The Endian matters only when you are writing memory as a collection of bytes (int, long, etc), and reading it one byte at a time (or, at a smaller size than you used to write it).
Not true, it also matter if you support writing on one machine, and reading from another machine, this include, but not limited to: storage, network protocol, encoding (eg. utf16/utf32).
If same machine is used, endianness does not matter even you write a long(or better, uintXX_t) then read it back as byte sequence and then cast it back.
Re: Endians
Posted: Thu Jan 24, 2013 6:45 am
by Griwes
BMW wrote:How does that have nothing to do with endianness?
Is it because we are reading it as an unsigned int, so the endianness doesn't matter?? If we were reading it byte by byte, would the endianness matter then?
Because shifts in C and C++ are defined to work value-wise, not representation-wise.
It would be stupid if `1 << 12` meant different things depending on architecture, wouldn't it...?
Re: Endians
Posted: Fri Feb 01, 2013 1:01 pm
by Love4Boobies
I didn't read the whole thread carefully but I did see many people claiming that representation is unimportant. This is not true whenever interchangeability is a requirement. The solution is serialization.
Re: Endians
Posted: Mon Feb 04, 2013 4:17 am
by qw
Love4Boobies wrote:The solution is serialization.
I think I am missing your point. Please explain.