Endians

[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?

[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.

[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.

[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

[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.

[Antti]

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.

[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".

[BMW]

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.

[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.

[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?

[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.

[bluemoon]

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.

[Griwes]

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...?

[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.

[qw]

The solution is serialization.

I think I am missing your point. Please explain.