On Fri, Aug 19, 2016 at 12:58 PM, Joseph Myers <joseph@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
