From nobody Sun Jul 2 16:34:02 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QvF4w10SLz4l9Sb for ; Sun, 2 Jul 2023 16:34:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QvF4t1P1zz3MxS for ; Sun, 2 Jul 2023 16:34:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=eM4woG4x; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688315660; bh=tkcoQzQcEuow/V708xVbo3oPyzLWJ3KU0g9AOjAXjpA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=eM4woG4xNfHalujeWOhe+sFmlUQSqOlNvvqfKRExN14mb5zCNdtO413SyYXMLzswUWBqdc12eub6rvZt6OZRJeMs5SNryyEe15atCtAQgpeE7EIliZYpUAdhgMn5MO3F4bko+y+KSVnCbYZ0NerSaaRENIKs+GMTS3dUBbV6dezgvi6gNsGH2XTtCLUKkGHDcyls8m1s1zMOVDxqVSlo5mqFI8izwI65N+yCJNXughhO9t7F6Mpwee2qe27PhSB3DSEl+79bwVeiS9tnjPcveqAIPrEa+lmGoUsyC/tVS6o0qkvx/N0SFpzHyd+qTyWXOa4PvrFJIurrSfSbDYe9cQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688315660; bh=S7qTTnb+BRcNTsK+t5qQQTiio5ZpoOTwiOKIApAJT3r=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=aRsKT6IH24m2T5x3EVtExT7M2+QzwtJaPkBDScknw/WR6Hj4ute+Jt/OGy8tm2baxpfVXCrSw1N38nav/FC/nPj4nwUVD4Lu85atsuAKDUEzFOon5jere+sxNOw0OBgowaBWROd63a0pQSi54bmXkhxjWAvVnV0sT1BCjHxD7oLdtnlEC+jM4QAu/Q01k99rcmOKkCjbofuB9F7+YYMzwiefdMJIb3I38r+Rdm97UpVkfbYEGTCq3AB+HU37qQsDqpk6kduhBDxsMO67BmOYROoIJVofHtXryvGKIIiFnHLMm4IwQhc5uSh/JOgCAxBcizxuzk1KjZFlFa8jsdPmOg== X-YMail-OSG: kQ7ti_QVM1kkrO3nBEgdOjwZI5SirxJs4CtpQKxc.Axlxzm02eDq88L4kmQhw3Z tLAAEClNLDpvj1ELzK4GcpZVfD0Ijdz3DGk8CQrNNk64FANIvMfbaw4O5jGi5NIxDEm_81RLPlli gLbRqgtdMFyGTeWuEQPCDw8IOxhui7qtRwHmFSLX5BSquHQBajXcTfxD9kf.rXaFw4SB1ZTlhi3C _PVxtCr0Lkw3NLxpgkmKusmtCc5urc0gdLL0PXJDcCQ818DzMBNt2WXPF9eAamIKQIox7arOjKqj alMjkOND8j0pTjKGEYmMq7s0LsUbkK4jRrYUyLGtQbV.juAGnmxviFbWRGKoqfUur3y7Xl1gu7wj qrPmhjWqFN2YXjnuvSuDwHCdRY3yjJdLTIkXOjp1e4Z0MNeLqwWcZs6LzcNwsfJm2C1Ysch4xjzh piblFFFQUZ8Lb_muqBKc28QsJqVC_sIUsR9IDkq7bB2EbP391Gc4M0ik4DGfcRvTSrRAjR66XNy4 GFLMaoW4XXUBHj7as8ASJgn2JvQsjDrZxzndml1_bZjL10aR3dvhEpAMw_aYgbfbJbk1I34P9RPx UgeEiXMLS5DYB0mAV_Qo96A7KRb7Hdtkfjm4PzKtoN3hEvjWDwTr8KUbNMuk.fRoNZ7prYeKw.p8 BHcl_ghP_T31Rz8jtqJ8O0CaWv_OsqpAcu5_4nUH3Qf6YbwMfJBjmdoI2xRNwk8.uiVTFXxBsDSz ooXpGety2JDxfa9ZoZtjhGw32Y9IGQq7lgYDJxh6D54J8T_INld2ILWsjc4H_tp7NkBWreEZSyrZ iYiGKwfsKb4R2CT7ankgFrEweCfOpHAaIa4aLSI0Jv2QcktbCnroWXXltM3pFe5qGCxKPuDbbg.F j9EYUtaGCL1jcSMuHk3.8YYD87FYoPIrkhCt0HHyi8pI_2Uss9frAWsYiujV8MN0a4SURPOHBHjZ 4d9mU02F3tV3Zg7PAU8NP8Gq2rMJcBq5FQyhztW.NKaLa4p_9z4JFgaLg.WpFz5EBwrVB86wgVzI m0d9gN.SWjO_hcVTSoS3w6.H9H1m5Jq49xJGVR7kw1xaGdhnTA.O5eoSMwy6RNwsf8cQ57Uw9UT3 uBvL3xQ0oXm.DrQs__VC8sq4eWO_UOLXR9Xy9.sPoF5gAikI2lHKuZda_4yLG0W0cpAfHdCXU__l oFZTsPiSWKF6eDSdlDtorv0_4iHnRwj5blkh0TP7kjv1R6KFzOYYHVtusnLPUzZYjjbgGpob_1.Z hl80s5fHP6CF7DkpRcmNkGLaCNuqVeX8oNkP5mMJG.vgVSkIi2DuJjZyTSsCuS6r_whS2AjK4a.V OjY3hcl4hxJYlr61O81eSECrxU0Vli72wJzeCRuP3_1m8WKtX6XFGHVT3h.xuOCelXLR6RdloNaf v2rKFxHgV1dfqeyZkp0bip0tNGrYcQ_zZdOQJPvJXPiIk0ICta.lHEQpmqCbq0_NcfiJ8vfPX3_M 0jTklz1pm7Ah2xBsO8dpF5Rg.YUXWy5NkwviXVR9CSKhCwAqoL_IcKGfKyZTW1gXuadqNWgq6gDd KUOkaisJ.JooW4NRtS0we99qK8mOFKLjKiInd0XgzE30JX.maBY6W0PIwGYiNcJSVXUDDm3B9uuP kF2_S_tVYafE0b3rc0cFofnIy_x.BuLgYuKDN7tFMoujYHbkFRcuTHRIK6gQXUaOr3.Jl3IQArcx cxkRX4pfAmXqlbFn4SDu1wLKX80ctHoszgjLrT9iFtcABYghcHc__w.n348.80UF7SizldsJEcjT IZ.T8r9JOFxfUHyE77J1D.4qFbNBlt2be0ryqkPLrh8YqchW3k_hFzKLqZGI4Y1AmASVclP8uJl3 1_J6eRHtSdC0fYMHmWzmlA9Nqbk3jqrDTqLAmT0OXYbo2_rkdBr71ru6xC0o4f9lO_hpWHFE5WjW IP3I.UjdDKkiZeN_L0QvQjq80Cgwj117Ae45aB3JO0PaymHuI2YyPGQC8Fo64VegQDtpU2IJ3W_S 3CNOkpy4HcynTHntgCfqOinEUs8CTcN39h5hprdbaUWWnkSO4sX6ShZXKnRZXM7sPWEAIATkRx0y L0tGLa_uhXzO3idDmhQtfPtb8H0fBIGfvEX3SCPjmHL3GfvySTM7T.Qh7szSCrstO22DEHMXNx2H Q0HrRzIkYUQEyE.Wn1VCsbnbCp_AJJerzQySdr0BpW4pmi7D719_mWZs60jzh9SB2ytasmEAHDni mXk5j_8XN6Eg45umD0JQSIbrT.Z2E0bqcgvWUlAMyYpD2ovQ9CQhM4FlO99g2GQBiacChtiwuO9q y X-Sonic-MF: X-Sonic-ID: 30e1bf89-8f72-411f-b357-960b30b24a03 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Jul 2023 16:34:20 +0000 Received: by hermes--production-ne1-6d679867d5-bcsgq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 62449367d6269a02f704446766281b3b; Sun, 02 Jul 2023 16:34:14 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: git: 005aa1743b42 - main - modules: bzero the modspecific_t Message-Id: Date: Sun, 2 Jul 2023 09:34:02 -0700 To: khng300@gmail.com, dev-commits-src-main@freebsd.org X-Mailer: Apple Mail (2.3731.600.7) References: X-Spamd-Result: default: False [-0.94 / 15.00]; NEURAL_HAM_SHORT(-0.94)[-0.944]; NEURAL_SPAM_MEDIUM(0.85)[0.853]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.35)[-0.349]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from] X-Rspamd-Queue-Id: 4QvF4t1P1zz3MxS X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N Ka Ho Ng wrote on Date: Sun, 02 Jul 2023 10:18:35 UTC : On Sun, Jul 2, 2023 at 6:03=E2=80=AFAM Ka Ho Ng = wrote: >=20 > > On Sat, Jul 1, 2023 at 7:13=E2=80=AFPM Konstantin Belousov = > > wrote: > > > >> On Sat, Jul 01, 2023 at 10:59:22PM +0000, Ka Ho Ng wrote: > >> > The branch main has been updated by khng: > >> > > >> > URL: > >> = https://cgit.FreeBSD.org/src/commit/?id=3D005aa1743b42b52fbd49b9d5ec448169= 02b6ee9f > >> > > >> > commit 005aa1743b42b52fbd49b9d5ec44816902b6ee9f > >> > Author: Ka Ho Ng > >> > AuthorDate: 2023-07-01 19:41:53 +0000 > >> > Commit: Ka Ho Ng > >> > CommitDate: 2023-07-01 22:58:46 +0000 > >> > > >> > modules: bzero the modspecific_t > >> > > >> > Per https://reviews.llvm.org/D68115, only the first field is > >> > zero-initialized, meanwhile other fields are undef. > >> This is not true. > >> > >> > > >> > 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. > >> What are non-active fields? > >> All fields with implicit initializers > >> "shall be initialized implicitly the same as > >> objects that have static storage duration." > >> > >> I do not think this is required for padding. > >> > > In that case, modspecific_t ms did become 0xaaaaaaaa00000000 on = amd64 if > > -ftrivial-auto-var-init=3Dpattern was specified. > > > > > >> > >> > 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. > >> > > >> > MFC with: 2cab2d43b83b > >> > MFC after: 1 day > >> Min MFC period is 3 days. > >> > >> > Sponsored by: Juniper Networks, Inc. > >> > Reviewed by: delphij > >> > Differential Revision: https://reviews.freebsd.org/D40830 > >> > --- > >> > sys/kern/kern_syscalls.c | 3 ++- > >> > 1 file changed, 2 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/sys/kern/kern_syscalls.c b/sys/kern/kern_syscalls.c > >> > index 234e51cfd280..0b51edf5e985 100644 > >> > --- a/sys/kern/kern_syscalls.c > >> > +++ b/sys/kern/kern_syscalls.c > >> > @@ -173,9 +173,10 @@ kern_syscall_module_handler(struct sysent > >> *sysents, struct module *mod, > >> > int what, void *arg) > >> > { > >> > struct syscall_module_data *data =3D arg; > >> > - modspecific_t ms =3D { 0 }; > >> > + modspecific_t ms; > >> > int error; > >> > > >> > + bzero(&ms, sizeof(ms)); > >> > switch (what) { > >> > case MOD_LOAD: > >> > error =3D kern_syscall_register(sysents, data->offset, > > > > > > Ka Ho > > > Since I missed the reply-all button just now, I resend this email. >=20 > Reading on N2716 one of the footnote stated: > "Note that aggregate type does not include union type because an = object > with union type can only contain one member at a time" >=20 > And below at 6.7.9.21 only aggregate was mentioned but not union, = which > matched what I observed with an `cc -ftrivial-auto-var-init=3Dpattern` > invocation. The context for modspecific_t is (looking in my source tree for main): # grep -r modspecific_t /usr/main-src/sys/ | more /usr/main-src/sys/sys/module.h:} modspecific_t; /usr/main-src/sys/sys/module.h:void module_setspecific(module_t, = modspecific_t *); /usr/main-src/sys/sys/module.h: modspecific_t data; /usr/main-src/sys/kern/kern_module.c: modspecific_t data; = /* module specific data */ /usr/main-src/sys/kern/kern_module.c:module_setspecific(module_t mod, = modspecific_t *datap) /usr/main-src/sys/kern/kern_module.c: modspecific_t data; /usr/main-src/sys/kern/kern_module.c: modspecific_t data; /usr/main-src/sys/kern/kern_syscalls.c: modspecific_t ms; This is C code, not C++ code. The languages are not fully matching in various details in some similar areas, especially when the vintages are not from a similar timeframe. Also, modspecific_t is a union: /* * A module can use this to report module specific data to the user via * kldstat(2). */ typedef union modspecific { int intval; u_int uintval; long longval; u_long ulongval; } modspecific_t; When I look up C's N2716 in: https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm I find: "N2716 2021/05/09 Tydeman, Numerically equal" with the link https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2716.htm . Its summary line is: QUOTE Summary: The phrases "numerically equal" and "numerically equivalent" = are used, but never defined. Also, they seem to add no value to just = "equal". END QUOTE (There is also: "N2847 2021/10/15 Thomas, C23 proposal - Revised suggested change from N2716" with the link: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2847.pdf .) This has nothing to do with what you are writing about. For C code, I suggest only using C langauge specification materials, not C++, unless the same source is to have dual language use for some reason. (I see no indication of such here. If such use is the intended context, please be explicit about that.) Also, using material from 2021 when FreeBSD is based on a older C standard version can have its own problems. If I remember right, FreeBSD is basically targeting C11 or so for its C code. An example quote from footnote 310 (for memcmp) in ISO/IEC 9899:2011 is: QUOTE The contents of "holes" used as padding for purposes of alignment within structure objects are indeterminate. Strings shorter than the allocated space and unions may also cause problems in comparison. END QUOTE Initializing .intval and then accessing .ulongval resulting in 0xaaaaaaaa00000000 as a possible result should be no surprise for C as far as I can tell. Based on what I'm reading, code that assumes otherwise is incorrect relative to the C language standard. It looks to me like the bzero use is trying to make changes to allow non-standard C code "still work". =3D=3D=3D Mark Millard marklmi at yahoo.com