On Fri, 13 Aug 2021 at 16:05, 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
On 8/15/21 5:44 PM, Peter Maydell wrote:
> On Sun, 15 Aug 2021 at 15:34, Philippe Mathieu-Daudé
> wrote:
>>
>> On 8/13/21 8:30 PM, Eric Blake wrote:
>>> FWIW, the POSIX wording is interesting - it requires portable
>>> applications to zero out sockaddr_in6 (and even states that memset()
>>> is no
On Sun, 15 Aug 2021 at 15:34, Philippe Mathieu-Daudé wrote:
>
> On 8/13/21 8:30 PM, Eric Blake wrote:
> > 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 hardwa
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
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 zer
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
