Re: [PATCH for-6.2 0/4] Zero sockaddr_in when initializing it

[Philippe Mathieu-Daudé]

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         }

[...]