Date: Mon, 3 Jul 2023 15:27:21 -0700 From: Mark Millard <marklmi@yahoo.com> To: Brooks Davis <brooks@FreeBSD.org>, dev-commits-src-main@freebsd.org Subject: Re: git: 005aa1743b42 - main - modules: bzero the modspecific_t Message-ID: <E27F699E-2CD2-48A2-BDA7-37765D371B0B@yahoo.com> References: <E27F699E-2CD2-48A2-BDA7-37765D371B0B.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis <brooks_at_freebsd.org> wrote on Date: Mon, 03 Jul 2023 21:24:11 UTC : > On Sat, Jul 01, 2023 at 10:59:22PM +0000, Ka Ho Ng wrote: > > The branch main has been updated by khng: > >=20 > > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D005aa1743b42b52fbd49b9d5ec448169= 02b6ee9f > >=20 > > commit 005aa1743b42b52fbd49b9d5ec44816902b6ee9f > > Author: Ka Ho Ng <khng@FreeBSD.org> > > AuthorDate: 2023-07-01 19:41:53 +0000 > > Commit: Ka Ho Ng <khng@FreeBSD.org> > > CommitDate: 2023-07-01 22:58:46 +0000 > >=20 > > modules: bzero the modspecific_t > >=20 > > Per https://reviews.llvm.org/D68115, only the first field is > > zero-initialized, meanwhile other fields are undef. > >=20 > > The pattern can be observed on clang as well, that when > > -ftrivial-auto-var-init=3Dpattern is specified 0xaa is filled for > > non-active fields, otherwise they are zero-initialized. > > Technically both are acceptable when using clang. However it > > would be good to simply bzero the modspecific_t in such case to > > be strict to the standard. >=20 > IMO this is a move in the wrong direction. We should see about > switching this file to C17 which IIRC removes this bug in the = standard. >=20 > Ideally we'd be moving to C23 where we can just do foo =3D {} > to zero things, but we've got a ways to go... Can you point me to where some (draft?) C?? standard material indicates that: A) pad bytes are to be determined to have a specific value? B) union bytes unused by a smaller size field that is the one = initialized are to be determined to have a specific value? My copy of N2176 for ISO/IEC 9899:2017 still has the J.1 Unspecified behavior wording: -- The value of padding bytes when storing values in structures or unions (6.2.6.1) -- The values of bytes that correspond to union members other than the one last stored into (6.2.6.1) As long as those are true, initializer notation is not guaranteed to avoid memory content leakage for the padding bytes and unused bytes for smaller union fields. (I'll not generate wording to deal with trap representations for such issues, something C++ avoids.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E27F699E-2CD2-48A2-BDA7-37765D371B0B>