Recent fread() bug on 64-bit FreeBSD archs

A commit to libc caught my eye tonight:

Edit src/lib/libc/stdio/fread.c
 Add delta 1.14.2.1 2008.12.13.16.53.35 ru

The commit which broke things was almost 3 years ago, to the day (December 2005).

The impact should be fairly obvious: on a 64-bit arch, the return value for fread() would essentially be capped at 4294967295.  Chances are few-to-none use humongous chunks, e.g. fread(&data, 8*(1024^3), 1, fp), but instead use smaller sizes… but such an assumption is ignorant.

Why this upsets me so much: because -Wall -Werror would’ve caught this mistake 3 years ago.  In fact, libc is the one place where this should be explicitly forced. I’d argue that such flags should be used across the entire buildworld chain as a whole, but people probably wouldn’t like buildworld taking twice as long as before.

Has anyone actually taken the time to look at how many warnings buildworld (and for that matter, buildkernel) emits?  The number is scary.  Some are redefinition warnings (such as in BIND, if I remember right), which can be safely ignored (but should be cleaned up regardless), but many are not.