Re: [Linux PATCH] fcntl: add new F_OFD_*32 constants and handle them appropriately

[Zack Weinberg <zackw at panix dot com>]

On Fri, Aug 19, 2016 at 12:58 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 19 Aug 2016, Zack Weinberg wrote:
>
>> (I'd still worry about invisible breakage of _applications_ due to
>> e.g. assuming sizeof(off_t) <= sizeof(size_t), but there's probably
>> nothing the _library_ can do about that.)
>
> We have the statement from the previous discussion that the change would
> break INN but distributions already dealt with LFS issues for it
> <https://sourceware.org/ml/libc-alpha/2014-03/msg00354.html>, but I expect
> that's the rare case, and not a significant argument against making the
> change.

INN was on-disk data structures containing off_t quantities, wasn't
it?  I was thinking more like

   struct stat st;
   fstat(fd, &st);
   buf = malloc(st.st_size);
   read(fd, buf, st.st_size);

which is catastrophically wrong with 64-bit off_t *but only when
size_t is smaller*, i.e. this won't have been flushed out by testing
in an LP64 environment.  Neither gcc nor clang issues any diagnostic
for the truncation in the call to malloc, even at -std=c11 -Wall
-Wextra -pedantic, and nothing bad will happen at runtime unless the
program is actually supplied with a >2GB file.  So it's a lurking
at-least-crash-perhaps-exploit.

(You *can* get a warning with -Wconversion, but who uses that?  I
wonder if there's something glibc can do in its headers to make
warnings happen in this circumstance.  Nothing comes to mind.)

zw