On 8/13/21 8:30 PM, Eric Blake wrote:
> On Fri, Aug 13, 2021 at 04:05:02PM +0100, Peter Maydell wrote:
>> The POSIX spec for sockaddr_in says that implementations are allowed
>> to have implementation-dependent extensions controlled by extra
>> fields in the struct, and that the way to ensure these are not
>> accidentally activated is to zero out the whole data structure.
>> We have several places in our codebase where we don't zero-init
>> sockaddr_in structs and so (at least in theory) might run into this.
>> Coverity spotted the ones in the net code (CID 1005338); the
>> others in this series I found by looking at all uses of sockaddr_in.
>> (The gdbstub patch changes also a sockaddr_un use, for symmetry.)
>>
>> Thanks to Eric for the analysis of what the spec says and why
>> Coverity is correct here.
>
> FWIW, the POSIX wording is interesting - it requires portable
> applications to zero out sockaddr_in6 (and even states that memset()
> is not yet a portable way to do that on exotic hardware, although a
> future version of POSIX may add a zero-bit constraint on
> implementations; in practice we only use qemu on hardware where
> memset() to zero properly sets pointers to NULL and floating points to
> 0.0).
So this checkpatch.pl error (inherited from Linux) is against POSIX?
2028 # check for static initialisers.
2029 if ($line =~ /\bstatic\s.*=\s*(0|NULL|false)\s*;/) {
2030 ERROR("do not initialise statics to 0 or NULL\n" .
2031 $herecurr);
2032 }
[...]
