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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30273 invoked from network); 24 Feb 2023 16:43:15 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 16:43:15 -0000 Received: (qmail 11390 invoked by uid 550); 24 Feb 2023 16:43:12 -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 11344 invoked from network); 24 Feb 2023 16:43:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bc7HKhwrX5jPS0yWWu1zcm2h4BidvPIg92WLLUEsaxI=; b=kmOA6GaAWD6yZWreisbWiR2+AqwZrO2Mjy85rF9yoMXWGwF3m3a3WrQP2dcrz+KcZT VcQEj2lCGPwH3AiP9l0bxAppBwHySaXyWnXrSzBbnVzflZ17DEcYz6O18ofLQzcam9XI zBRkMHzTiwc4pe7T3akcfWqmWbrqGyOuNrGy7gUHeT5N1tFx4VKnuwnfaNtfaDoMSyhT oyt5bkah/62xpREIS2pbo9uyXxyL7X+Th5DxsN+i6J1hGWTYZ2dnLUTZY2+amOtWtwvu V4/u7b4th9DlTj4MiKt61tOVHmy9dvPI0ELzzOPUPCIuT7yf5fEL3k6BEg2kz1z40P0f tMJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bc7HKhwrX5jPS0yWWu1zcm2h4BidvPIg92WLLUEsaxI=; b=qA1VS6GrjPUsolANPG9/qMGvGsiBPoGwy7LyernxhqV8/QOXV6CYKEdSAIF7IlBUVW kR2hvhujuOfhsg6i+oMJ6Jqf8295DjfHSKC6dO/oX5AfT4b0Caaikla1pYIBsLgo1wUI BWrg61muAbvAWSi4k2V3ToUwCi0i1UgYvxIS74vZfSpDHwTzC+BvSIzS8fu9oRTj4Qqh 0L5hyW+Lzp6I34tKHWtHnR0jEfasqb/MHaB2vbOMSaJpC2n76TMkXocl6DztTHjdqZ77 RKPodVjgne6vI12kQr6z1Ez+t8Bn+sEJNUaCp+vrxpWrdElPHXG2fyA/XLM4lLqKHQHD O3Tg== X-Gm-Message-State: AO0yUKW4Ft7RBjAORzoA4qJ/2J53WD3kUXrskY1p9bmLLRkwJfq/QteE PUsUquH21GbzalPWlrkJvby23B0KSe56KBOir2hqyw5GdclwfA8Vm/Y= X-Google-Smtp-Source: AK7set8S4RMEMdbbWL6ak6DTM/UKj2iNTkgWgXV3PVqEEG1saPpLFAQEToO5nxezsmE3JLuyN0r572HppcODiYgWq1E= X-Received: by 2002:ad4:57d0:0:b0:56e:a066:5016 with SMTP id y16-20020ad457d0000000b0056ea0665016mr3037878qvx.5.1677256978999; Fri, 24 Feb 2023 08:42:58 -0800 (PST) MIME-Version: 1.0 References: <20230224133413.GE4163@brightrain.aerifal.cx> <20230224135511.iunglqtcvpjeqgtv@gen2.localdomain> <20230224140739.GF4163@brightrain.aerifal.cx> <20230224141731.dm4w7fbfkczbx42e@gen2.localdomain> <20230224151334.ycgddzdc4o5a4m5q@gen2.localdomain> <20230224174010.7b8e2401@inria.fr> In-Reply-To: <20230224174010.7b8e2401@inria.fr> From: enh Date: Fri, 24 Feb 2023 08:42:48 -0800 Message-ID: To: musl@lists.openwall.com Cc: Tamir Duberstein , NRK , Rich Felker Content-Type: multipart/alternative; boundary="0000000000006ea40d05f574d21d" Subject: Re: [musl] undefined behavior in fread.c --0000000000006ea40d05f574d21d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2023 at 8:40 AM J=E2=82=91=E2=82=99=E2=82=9B Gustedt wrote: > > on Fri, 24 Feb 2023 11:12:11 -0500 you (Tamir Duberstein > ) wrote: > > > I agree, the caller's behavior is UB. I'll send them (freetype2) a > > patch. > > > > That said, do we want to avoid internal UB here anyway? > > I am not sure that I even understand what "internal UB" is supposed to > mean. > > > - As mentioned earlier, glibc avoids the UB (and the lock). > > - llvm-libc does the same starting with > > https://github.com/llvm/llvm-project/commit/53c251b > > - uclibc avoids the UB but still locks: > > https://github.com/gittup/uClibc/blob/9dbf00b/libc/stdio/fread.c#L25 > > - FreeBSD avoids the UB but still locks: > > > https://svnweb.freebsd.org/base/head/lib/libc/stdio/fread.c?view=3Dmarkup= #l76 > > - Android (bionic) avoids the UB but still locks: > > > https://cs.android.com/android/platform/superproject/+/master:bionic/libc= /stdio/stdio.cpp;l=3D1099;drc=3D4aa8f499f21ebf84101de34d68682d5388667001 > > > > Does this persuade? > > Me personally not much. The only thing that would help applications to > write portable code is to put an attribute on the pointer argument > such that bad calls get diagnosed if possible. > (bionic's actually working on the larger "annotate all the functions" project, but hasn't got as far as stdio.h yet :-) ) > J=E2=82=91=E2=82=99=E2=82=9B > > -- > :: ICube :::::::::::::::::::::::::::::: deputy director :: > :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: > :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: > :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 > <+33%203%2068%2085%2045%2036> :: > :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > --0000000000006ea40d05f574d21d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 24, 2023 at 8:40 AM J=E2= =82=91=E2=82=99=E2=82=9B Gustedt <jens.gustedt@inria.fr> wrote:

on Fri, 24 Feb 2023 11:12:11 -0500 you (Tamir Duberstein
<tamird@google.co= m>) wrote:

> I agree, the caller's behavior is UB. I'll send them (freetype= 2) a
> patch.
>
> That said, do we want to avoid internal UB here anyway?

I am not sure that I even understand what "internal UB" is suppos= ed to mean.

> - As mentioned earlier, glibc avoids the UB (and the lock).
> - llvm-libc does the same starting with
> https://github.com/llvm/llvm-project/commit/= 53c251b
> - uclibc avoids the UB but still locks:
> https://github.com/gittup/u= Clibc/blob/9dbf00b/libc/stdio/fread.c#L25
> - FreeBSD avoids the UB but still locks:
> https://svnweb.fre= ebsd.org/base/head/lib/libc/stdio/fread.c?view=3Dmarkup#l76
> - Android (bionic) avoids the UB but still locks:
> https://cs.android.com/an= droid/platform/superproject/+/master:bionic/libc/stdio/stdio.cpp;l=3D1099;d= rc=3D4aa8f499f21ebf84101de34d68682d5388667001
>
> Does this persuade?

Me personally not much. The only thing that would help applications to
write portable code is to put an attribute on the pointer argument
such that bad calls get diagnosed if possible.

(bionic's actually working on the larger "annotate all the= functions" project, but hasn't got as far as stdio.h yet :-) )
=C2=A0
J=E2=82=91=E2=82=99=E2=82=9B

--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_= Gustedt ::
--0000000000006ea40d05f574d21d--