[I note the guarantee in read(2) and point out that many programs rely
on it by reading it a file with a single system call.]

> Of course, programs doing what you describe have, aside from *not*
> relying on that assumption, been broken since the introduction of
> ftruncate(2).

A poor argument.  Suppose, for instance, that the file you're reading
in lives in a news spool.  Truncating such a file is something you
don't ever to; it's akin to overwriting it with zeros.  Either way,
the process reading the file isn't going to be able to get useful data
out; getting an error from read() and reporting it is perfectly
appropriate behavior if the illegal truncate operation happens in the
window between stat() and read().

If you actually do expect the file to be modified (other than by
atomic replacement) while you're reading it, you need to be doing some
kind of locking anyway.