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 30229 invoked from network); 24 Feb 2023 16:42:56 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 16:42:56 -0000 Received: (qmail 9544 invoked by uid 550); 24 Feb 2023 16:42:54 -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 9508 invoked from network); 24 Feb 2023 16:42:53 -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=zxefwbfaXxDihWCxOuBa7afVwSVJLgMDN4RPEaBazB8=; b=Bz7nW5DDaugMK422RjXzlQo8r9kkCTZkFsfOyoi7gnH48njHbz89cNV1YAGNuOqj8y 6odu5fsIRaFuv2ot0eb8B+zTl7ZxhI5bEpgBaf5lwMdz5VYIfCyKaVTJGF2yPeu5dnn3 QbFARK3jkjcK6fCO5rLuDWDuckp98BCzBay5oQjOT5LIyFEEu7j6tt8YqJrUJPhyFetH 3+hrVRs/+lnwWssvU+W7WtBtPGtiC0BqXALcYs0f9tzJKewqalx2bVSVlL/eo7rRnteI btgjmNK2a2ZeihKYHsFyt9kyfFUluidg5G/GVy47F940OEzI7wmPToGGR9ycjHVwN7te X7Pg== 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=zxefwbfaXxDihWCxOuBa7afVwSVJLgMDN4RPEaBazB8=; b=lpXM04vJDahixl/OddM0/b2z+VkyUT1VGAnCC90kWzR6z5oZwct1LK2upU6AsZcOqI ATbpwSGR4p9OFzoIEC5R2CY0MqJiVKvA3l9q7YXHMOcTQ5LJr+QxccAWwWdCWu7ik2cp R9fqoQsgcg5xqr+5M6sg5H1lZm8+7Fu96/kPYbQQpNIvqBcRXixBZwpisTwKAm1FTUiH bEW2Rtexk8c8C5kapqYS6zechWKV6ZrTZ+zKbBrMI/rODnOC1+j32lDfcobFQg3RpPnI mcrXJahsUBD0CxgPSNuM7Pm5QcuHoP8YK/utxMp4A3FinjudSUGOXfPsO5OD144gtxu0 rnlQ== X-Gm-Message-State: AO0yUKUMOgryjyJOtNiHoRapOIPhaZ5dqRNHxdVuDHLTkEvwvlfTjmSW bs9ntLbIgRALY+TsUjFZDM2LgVoUjKHvH5+ZrOQVuZWcQl8h8sb59NQi X-Google-Smtp-Source: AK7set9b/077+71fN7N/8kuocMze9Pm8PLgzWsA62ZRYEYTxBEofVvfdxEjPN406FebhD2RuBydSnCTK16tMUpt60S0= X-Received: by 2002:a81:b718:0:b0:533:9185:fc2c with SMTP id v24-20020a81b718000000b005339185fc2cmr4875355ywh.7.1677256961436; Fri, 24 Feb 2023 08:42:41 -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: Tamir Duberstein Date: Fri, 24 Feb 2023 11:42:30 -0500 Message-ID: To: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= Cc: musl@lists.openwall.com, NRK , Rich Felker Content-Type: multipart/alternative; boundary="000000000000628f8b05f574d1c3" Subject: Re: [musl] undefined behavior in fread.c --000000000000628f8b05f574d1c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Internal UB means "applying zero offset to null pointer" when the caller passes (NULL, _, 0, _). Does such an attribute exist? On Fri, Feb 24, 2023 at 11: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. > > 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 :: > --000000000000628f8b05f574d1c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Internal UB means "applying zero offset to null point= er" when the caller passes (NULL, _, 0, _).

Does su= ch an attribute exist?

On Fri, Feb 24, 2023 at 11:40 AM J=E2=82=91= =E2=82=99=E2=82=9B Gustedt <jen= s.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.

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 ::
--000000000000628f8b05f574d1c3--