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
warning.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
