From: Rich Felker <dalias@libc.org>
To: "Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>
Cc: Tamir Duberstein <tamird@google.com>,
musl@lists.openwall.com, NRK <nrk@disroot.org>
Subject: Re: [musl] undefined behavior in fread.c
Date: Fri, 24 Feb 2023 15:07:19 -0500 [thread overview]
Message-ID: <20230224200718.GG4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <20230224174010.7b8e2401@inria.fr>
On Fri, Feb 24, 2023 at 05:40:10PM +0100, Jₑₙₛ Gustedt wrote:
>
> on Fri, 24 Feb 2023 11:12:11 -0500 you (Tamir Duberstein
> <tamird@google.com>) 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=markup#l76
> > - Android (bionic) avoids the UB but still locks:
> > https://cs.android.com/android/platform/superproject/+/master:bionic/libc/stdio/stdio.cpp;l=1099;drc=4aa8f499f21ebf84101de34d68682d5388667001
> >
> > 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.
Likewise. The recent atol thread seems relevant, where my view was
that it's better to allow the overflow to happen when the caller
invokes UB by passing an argument that overflows, so that a libc built
with sanitizers would naturally cause a trap. The same applies here.
If we make no change, a libc built with sanitizers would automatically
trap when NULL is passed to fread.
Rich
prev parent reply other threads:[~2023-02-24 20:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 12:52 Tamir Duberstein
2023-02-24 13:34 ` Rich Felker
2023-02-24 13:53 ` Jₑₙₛ Gustedt
2023-02-24 13:55 ` NRK
2023-02-24 14:07 ` Rich Felker
2023-02-24 14:17 ` NRK
2023-02-24 14:42 ` Tamir Duberstein
2023-02-24 15:13 ` NRK
2023-02-24 16:12 ` Tamir Duberstein
2023-02-24 16:40 ` Jₑₙₛ Gustedt
2023-02-24 16:42 ` Tamir Duberstein
2023-02-24 17:00 ` Jₑₙₛ Gustedt
2023-02-24 17:07 ` enh
2023-02-24 17:32 ` Tamir Duberstein
2023-02-24 16:42 ` enh
2023-02-24 20:07 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230224200718.GG4163@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=jens.gustedt@inria.fr \
--cc=musl@lists.openwall.com \
--cc=nrk@disroot.org \
--cc=tamird@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).