On Mon, 12 Feb 2018 13:15:45 +0000 Daniel Stone <dan...@fooishbar.org> wrote:
> 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.
Yes, that warning happens on syscall. I was thinking about
memcpy'ing stuff around otherwise.
Thanks,
pq
pgpyorPgNjzhc.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
