From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16203 invoked from network); 3 Jul 2023 22:30:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 Jul 2023 22:30:54 -0000 Received: (qmail 23737 invoked by uid 550); 3 Jul 2023 22:30:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23705 invoked from network); 3 Jul 2023 22:30:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s2048; t=1688423438; bh=pYGHittw9vhr63UckLFPmz/KaWvAiuZUzMdKu2ZL2ns=; h=Date:From:Subject:To:References:In-Reply-To:From:Subject:Reply-To; b=qy+cO05bZp2vRbgJh9sSmCDqN1XrkSyqoR93yce0dRiiW4zxpnQyKe4xhzjSw1rzZPNQ7RK04WkomcT4mw/KVm7ETGGdtn/XHC/wYKAhSzHQ2w/BNPNksXA0EUlUmDDEK5xLgtOLHr88n5xz4p2yXpVyeLCINKzBONcmJUMXixm4+wiXfuGyucslDjyrnxNZHd/YoMVZWveutxQ0DbtvzRHDcjHtfp1dNxTeCxqqXn5uAZS1tC0TXH4lFt8ldPMW+U+WuVz+lzYQaBxIXd+an3krCzOy/AF6KhExW2lgkGagVL90Ke4+F44EjjTOM7gRuVTdWmkYfE6vfrq01JTXvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688423438; bh=CFIDX3GDov1M0XfJ1HsmatXtSAMTo4Hf/nXJTHDY0qB=; h=X-Sonic-MF:Date:From:Subject:To:From:Subject; b=CMb32Zv/JM2I2Qg0o1Nj/CqG/flzaDHHWGPG5ws4QAo1cmsqdmN46oyWWm5X7TndeCet8cccPVdC+N5VCCkw095lC59NYNleyBhEnpr9fAQCGgzp9P80lv+qnxPGjxQ3CpbuOnWwUUcPQsgedJvXRZ1pNOr06f/yrwok5s0/YQ/WKVnTNtRHjpl5gbYMwVHMEhOBLs8dpO5i4S+aeLkpkNHWzCAh6fBcdKxCE4McmTuoJA9kKs3FaJOQIyNUV1x0u//eqWKva1diYeJB7pR08XUggQZpVDn1KuJWJW0mMrNXecFn6CiWpAATtziBLqQocPILEXVfxpwOAE9aPqrqXw== X-YMail-OSG: ynYdhpgVM1mEG0.PyvErWA35hRESmbrIBs6V53RSs9ZCRy4GzBs5bXl6fp.i2Zl 7nF.7X6b8OFE3Hf5IWQYRllLsJYS560HHTRr0qEps3WmdvucOytE6PGzOAGXVUflwC5JmMzlhpge OGM_Z6PCz_WfMSjD9W.ka0haYsOZ0nyZy3.2XXPdeDGrY0hYP02Sof3XtaKYilQA7794tsQsv.JL u34bVJmXlbEbfJb3d1HVHe6lkwkkH1eNyCVWD.NblTTd7IU0nSDMRNuGKQIurrjk32BPBDGPFhuA dyv3VqH1VG_X97Ob94FqIlH095H0TGyQF7wgL4J2LBcntNjIp7jcftbBUwgO9mR9sjQuLXjFusA1 0Sbqy8LCvNbCXVDracm7FSmxiLMTswkAGd7zEVhJ67iHxVdWb2RekjgRA.7rPBJ41U5SLQeYZCCa n1trpXY12S2qKpt8XrzC_gRzTx0YlMKGfC4crzbr224xxtfglycXdEJlH3UYSYQnNEm.kcB8HHbY 25H9q.bT_LJwIxuRoh3u0OO2eb3ESq4izaOR14xujqGJdTiwTQDSh86P.vRtxRLn9DyIOaf.XYhM 6qbaABoOf1_vl6SsFg96K7tOEzNFkGgOf9dlu548k_zzIx3KrYFYXnsEM_tjgX54q09ShPpFP0VU Oy.VwTed1GREASZemDoO9nSG3V0csaGYN5Eukl8HVeSXZAd61Ppp0ZhV2lvANThZCwKoqC85r4k7 w2O8i_G0DtAuI8M.2nGIPGv6d3ckxkb1RVar2.YDFAWrrTB16.0PCIcXFa1hFBIWM5Ryr3z3Vni8 cILqbDQAfiDJ_u3VfsU26IqQPcjUU0Xyr7fBSoaJRzSjCv1_mibGkXjzCUeIccKW0T6.5XvxRuTP .8hgd.EffwyBYHl5LpGSu4rzQ1XPS9YNvlHSk4QwoNdtzCnVagJEJoUA3iwYGEULVO0YKuNKWyxV 56_SZEYd3vrgrFdGF3tiYIvWxGYCW9ekPx8jw8WC5gulWV6hz2P2KuyQ3BO3Q0ASFiQs84kCqepI 7_472nAbye929SHP0cQva6B457M_3AbsES3zDCNGz5_2D5sOf3bLYJPnHzD7a91CF_mOdXLj2si8 VyU._MBCPM_aM3uUm7laCVAfw.w8OImmO10cJzK_bSjrePxRZQkCRFuncfkXrIJwl1TetyDDBKp8 d9btNravZTnq4zmUXbNZVgmaQGWWNS4LnfG20oHb0hFQJSWOURS.GzHiS_HJ0ntR2niBZCKsVUvO 7NvE8hV3f7LeX2WQr6XpH4bh9PImnRkBztDtaZUhiCIXkSAqcxikCBR6MEXzBv40yUnVDvS2uL8U 6KviKl6e93X_Z5t__F1pVOYlJpeUmhKax0Nu_DMa2z59akvRiNXbN5Ny6_KYHliQiGppsDd3GHGF wj3Uwg7a.ZcrzW3JfpqXnQS9F3d6UsMOKIteb50o.sNsubkLHlqwBnqBJOZSBAv8X6JFfofZ9AiC 80d_LDHXP4QYn620ouVF5X_Fs2pWGK7PEzAu5Gw8JZmezo72CvCRmMd7NS_F5zjTn_w26mLTXIk. HMrhpr0gNy.b4gx1TT_D4BxY63ctJ2Q7svGUr7Uy2ygxC2.OMYx7AtATSWkM510SDQBORAUlwC8c iUKbfxSqLWWCma4oh5GuCY8AL4bkXqueEGGj3GAXXLn_E0UPCLNd_QQP.PRfil12VZthP9GgcA.E g0PnhafIFdkEqC4bd9BjaGJpkvEQ34mwUWTslXyrKKaYqRnUn1JvwvPgYsTlJF2jRFSTNOIQvZ1I yWro3QIJyeOVlDS9onJIPHaADu4sI9hB10VEf74NNCCFbgPVXCbsqvlEQVLvFnTA0M6rxII0ySmk 0FtZQ6FpWBGMe5ZZzLgMJYwETWnwUi0mRrYqHJcGUBrt_F06bFOOHQLcUEld0TQzQCRxxmFdgNSF Hzn.YY5Vy9ewQ1cXgmEOVOTQKUobFHHfS_Sqg9iYNfVp2JB9t0lKa3t8_Ah03uC5X59QeR9EzH4L vyYe0beeg46EuoYTH6qIFjGF8raYhC2fbJte8ea5AJImUpTQir06hxLYa6FmvPyopTPRXrsWgg0s E5kGEOAcrxjNwgGeej9bgrkmb7s35Jx7uXMz8LBolJjS93tddh3aQJb0B8aZBSf8YU1ilP4hpw5l DYwg8_OZTfI2ot4X493vdiiUepL8juyc3AsJ0RuUt2Q4mY8syIvQrDuIdeQrWHEDWuMUGoe6UyR4 lRuF7MhKt_CKRJNltEgtO X-Sonic-MF: X-Sonic-ID: 43482d6c-4b73-4f4f-a6e9-25ff7c5e94c2 Date: Mon, 03 Jul 2023 18:30:28 -0400 From: "Alex Xu (Hello71)" To: musl@lists.openwall.com References: <1688401586.hkqjuyrd3s.none.ref@localhost> <1688401586.hkqjuyrd3s.none@localhost> <20230703195957.GZ4163@brightrain.aerifal.cx> In-Reply-To: <20230703195957.GZ4163@brightrain.aerifal.cx> MIME-Version: 1.0 Message-Id: <1688416766.ewsth12535.none@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Subject: Re: [musl] fix various warnings/theoretical UB Excerpts from Rich Felker's message of July 3, 2023 3:59 pm: > On Mon, Jul 03, 2023 at 01:55:57PM -0400, Alex Xu (Hello71) wrote: >> From b98f243e7921ddff6978ee9b0ce9f08efaa17951 Mon Sep 17 00:00:00 2001 >> From: "Alex Xu (Hello71)" >> Date: Sun, 2 Jul 2023 20:29:41 -0400 >> Subject: [PATCH 2/4] __year_to_secs: fix dangling pointer >>=20 >> C11 6.5.2.5p5: >>=20 >> > If the compound literal occurs outside the body of a function, the >> > object has static storage duration; otherwise, it has automatic >> > storage duration associated with the enclosing block. >>=20 >> gcc also warns about this. >> --- >> src/time/__year_to_secs.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >>=20 >> diff --git a/src/time/__year_to_secs.c b/src/time/__year_to_secs.c >> index 2824ec6d..d215880a 100644 >> --- a/src/time/__year_to_secs.c >> +++ b/src/time/__year_to_secs.c >> @@ -10,9 +10,9 @@ long long __year_to_secs(long long year, int *is_leap) >> return 31536000*(y-70) + 86400*leaps; >> } >> =20 >> - int cycles, centuries, leaps, rem; >> + int cycles, centuries, leaps, rem, tmp; >> =20 >> - if (!is_leap) is_leap =3D &(int){0}; >> + if (!is_leap) is_leap =3D &tmp; >> cycles =3D (year-100) / 400; >> rem =3D (year-100) % 400; >> if (rem < 0) { >> --=20 >> 2.41.0 >=20 > Seems like a bogus warning. The enclosing block is the whole function, > the same as the lifetime of the pointer. This might merit > investigation on whether GCC is doing something wrong though.. As Jens says, an if statement "is a block whose scope is a strict subset=20 of the scope of its enclosing block. Each associated substatement is=20 also a block whose scope is a strict subset of the scope of the=20 selection statement.". >> From a30c4ab397af040d10d978d97dd4a6835d4b99a8 Mon Sep 17 00:00:00 2001 >> From: "Alex Xu (Hello71)" >> Date: Sun, 2 Jul 2023 20:54:45 -0400 >> Subject: [PATCH 3/4] fix mismatched VLA parameter types >>=20 >> gcc warns about this, and it's probably technically UB >> --- >> src/internal/procfdname.c | 2 +- >> src/prng/seed48.c | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >>=20 >> diff --git a/src/internal/procfdname.c b/src/internal/procfdname.c >> index fd7306ab..bfa3e7e5 100644 >> --- a/src/internal/procfdname.c >> +++ b/src/internal/procfdname.c >> @@ -1,6 +1,6 @@ >> #include "syscall.h" >> =20 >> -void __procfdname(char *buf, unsigned fd) >> +void __procfdname(char buf[static 15+3*sizeof(int)], unsigned fd) >> { >> unsigned i, j; >> for (i=3D0; (buf[i] =3D "/proc/self/fd/"[i]); i++); >=20 > This was raised/proposed before and is probably an okay change, but > I'd like to understand what the reason "it's probably technically UB" > is. >=20 >> diff --git a/src/prng/seed48.c b/src/prng/seed48.c >> index bce7b339..7b789086 100644 >> --- a/src/prng/seed48.c >> +++ b/src/prng/seed48.c >> @@ -2,7 +2,7 @@ >> #include >> #include "rand48.h" >> =20 >> -unsigned short *seed48(unsigned short *s) >> +unsigned short *seed48(unsigned short s[3]) >> { >> static unsigned short p[3]; >> memcpy(p, __seed48, sizeof p); >> --=20 >=20 > This one is almost surely not UB because there's no static and the 3 > is ignored. The question is just whether the static produces a > difference in the declaration type that makes them clash. After reading the function declarations section in the C2x draft, I=20 think you're right. These are both well-defined because they are=20 adjusted to the same pointer type, because neither the static nor=20 non-static sizes are actually propagated to the pointer type. Thanks, Alex.