Re: [musl] undefined behavior in fread.c

[Rich Felker <dalias@libc.org>]

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