Re: [Qemu-devel] SLIRP warning messages displayed while compiling

[Eric Blake]

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