Hi Pekka,

On 12 February 2018 at 13:11, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Mon, 12 Feb 2018 12:59:22 +0000 Daniel Stone <dan...@fooishbar.org> wrote:
>> On 12 February 2018 at 12:51, Pekka Paalanen <ppaala...@gmail.com> wrote:
>> > I believe nothing is depending on the values of implicit padding bytes
>> > in structs anyway, if such happen to exist and if compiler would happen
>> > to leave them uninitialized.
>>
>> Hmm. On the other hand, if the ={} form only zeroes bytes accessible
>> via members, might this caveat not defeat the purpose of the patch?
>> IOW, if there is implicit padding not cleared by this assignment form,
>> but something is copying the entire size of the struct, that may be
>> treated as a read from uninitialised memory.
>
> True. The same caveat applies to anything we initialize without a full
> memset. I'd think it to be so common though that tools like Valgrind
> might have special-casing there.

Part of the point of the Valgrind warning is to avoid information
leaks. If you transmit uninitialised bytes somewhere - e.g. from
compositor to client - then you could be disclosing information you
shouldn't. It's harmless in this case, but Valgrind can't know that.
In the general case though, it seems better to be totally sure, if
that guarantee isn't made by the C standard.

Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to