After pulling in the latest changes, we now trip over UB in fread.c at https://git.musl-libc.org/cgit/musl/tree/src/stdio/fread.c#n21 on a `fread(NULL, 1, 0, ...)` call. `dest` is `NULL`, and incrementing a null pointer (even by zero) is UB. Here's the stack trace:

../../zircon/third_party/ulib/musl/src/stdio/fread.c:22:10: runtime error: applying zero offset to null pointer
  #0    0x00008037bf602a6c in fread(void* restrict, size_t, size_t, FILE* restrict) ../../zircon/third_party/ulib/musl/src/stdio/fread.c:22 <libr.so>+0x168a6c
  #1.2  0x0000421373b5f4ec in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d4ec
  #1.1  0x0000421373b5f4ec in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d4ec
  #1    0x0000421373b5f4ec in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d4ec
  #2    0x0000421373b62684 in handlePointerOverflowImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x40684
  #3    0x0000421373b6239c in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4039c
  #4    0x00008037bf602a6c in fread(void* restrict, size_t, size_t, FILE* restrict) ../../zircon/third_party/ulib/musl/src/stdio/fread.c:22 <libc.so>+0x168a6c
  #5    0x00004347972c0934 in FT_Stream_Seek(FT_Stream, FT_ULong) ../../third_party/freetype2/src/base/ftstream.c:64 <libfreetype2.so>+0xf1934

I think instead of `nmemb = 0` on line 10 that should just return.

I've confirmed glibc does a similar check and avoids UB in this case. See https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/iofread.c;hb=HEAD#l35 and https://godbolt.org/z/cYc9rG1ea.

Please CC me on responses as I am not a subscriber to this mailing list
per the guidance on https://musl.libc.org/support.html.

Thank you.
Tamir