On 08/12/2017 06:29 AM, Samuel Thibault wrote:
>> Alignment is architecture-dependent, and the compiler
>> can't know the alignment requirements for every
>> architecture.
> Sure.

True, but we can at least guess alignments that don't require padding,
and then be told by the compiler if our guess was wrong when porting to
a new system, and update our guess accordingly with more ifdefs (struct
ip6 is already using ifdef HOST_WORDS_BIGENDIAN for that reason).

>> There's no rule in C that says that uint16_t only needs 2 byte
>> alignment and not 4 on some hosts.
> Are there really systems where that happens?  Such systems would have to
> pad uint16_t arrays then, really?

uint16_least_t occupies only 2 bytes, but C and POSIX allow systems
where uint16_t is larger than 16 bits (most likely, 32 bits).  I don't
personally know of such a system; and it's most-likely to be a non-POSIX
system (perhaps one where sizeof(int) == 1 because the smallest
addressable integer is 32 bits).

>> (Also I just noticed 'struct ip6' uses bitfields:
>> that's badly non-portable if it's trying to
>> match an on-the-wire layout.)
> struct ip has been doing so for so long too.
> I'm not saying the code is perfectly portable, I'm just saying it's
> portable enough for being both practical and readable.

Here's an idea:  Instead of using struct ip6 { ... } QEMU_PACKED, use

struct ip6 {
QEMU_BUG_ON(sizeof(struct ip6) != 32);

so that the compiler explicitly chokes if it introduced any padding, and
then we know all our accesses are naturally aligned which shuts up the

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to