Endianness of structure/union

[SSM]

Hi,

Does C standard comment about "Endianness" to be used
to store a structure/union variables?

Thanks & Regards,
Mehta

 

[Richard Bos]

Does C standard comment about "Endianness" to be used
to store a structure/union variables?

Not if you mean the endianness of the various members themselves. What
it does require is that:
- for a union, all members start at the same address, which is also the
base address of the union;
- for a struct, all non-bitfield members start at different addresses,
with the first declared member having the lowest address, and so on in
order of declaration;
- bit field members have no address as such;
- there may be padding between two struct members and after the last,
but not before the first.

This is similar, but not equal, to endianness.

Richard

 

[Alexei A. Frounze]

Does C standard comment about "Endianness" to be used
to store a structure/union variables?

AFAIK, no. It can be anything, depending on the CPU for which you compile
your source code.

The only place in an application where endianness would matter is I/O (file
system, network or any other device consuming and producing data in big
chunks). Only there you should care about the endianness if you exchange
data with anything else but your own application.

There's a way to make the application more portable across systems with
different endianness. Send/receive integer numbers octet per octet (note
that by octet I mean an 8-bit integer, which is not necessarily a byte/char
as byte/char has different bits on different systems) in a fully defined
order, either least significant first or most significant first -- pick one
and stick to it. Slice the numbers into octets by shifting and masking --
this will make it independent from the CPU's endianness. It's OK to send the
numbers as text too but that's obviously too much of overhead in many
applications. The raw data, which you don't know and don't process, is to be
sent as-is, preferrably as octets too, best if octet=byte(char), if this
equality doesn't hold (byte/char is bigger than octet), then you must make a
decision as to how to get it out, as octets or as bytes/chars and if as
octets how you slice the date into them (again, least significant first or
most significant first).

Alex