On Sat, Apr 25, 2015 at 04:06:23PM -0400, Matt Whitlock wrote: > On Saturday, 25 April 2015, at 11:38 am, Rich Felker wrote: > > On Sat, Apr 25, 2015 at 04:53:33AM -0400, Matt Whitlock wrote: > > > This solves some of the problems arising from Bionic's off_t being > > > 32 bits wide despite _FILE_OFFSET_BITS==64. See BusyBox bug #6908. > > > > > > Note that this doesn't solve all such problems since Bionic lacks > > > 64-bit variants of many standard I/O functions: open, creat, lockf, > > > posix_fadvise, posix_fallocate, truncate, sendfile, getrlimit, > > > setrlimit, fopen, freopen, fseeko, ftello, fgetpos, fsetpos, > > > mkstemp. > > > > As long as that's the case, I think this approach of trying to fake > > 64-bit off_t on Bionic is dangerous and probably best omitted. IMO we > > should either be pushing for Bionic to fix these things or sticking > > with 32-bit off_t on Bionic and treating that as a limitation of the > > platform. > > Don't throw the baby out with the bathwater. Bionic *does* support > large files. In fact, it's mandatory in some cases: there are no > 32-bit versions of stat(), lstat(), fstat(), fstatat(), statfs(), > fstatfs(), or getdents(); and struct stat, struct statfs, and struct > dirent are equivalent to struct stat64, struct statfs64, and struct > dirent64 from Glibc, respectively. > > Furthermore, while Bionic does support 32-bit lseek(), pread(), > pwrite(), and ftruncate() with 32-bit off_t, it does also have > lseek64(), pread64(), pwrite64(), and ftruncate64() with off64_t. > > In short, Bionic has most of the syscall-level support introduced by > _LARGEFILE64_SOURCE in Glibc, but they did not implement the > transparent migration introduced by _FILE_OFFSET_BITS==64. This is > easy to implement atop Bionic, however, as it is simply a matter of > mapping the relevant 32-bit types and functions to their 64-bit > equivalents. (See feature_test_macros(7).)
This really can and should be fixed at the header level for Bionic. Nobody should be writing foo64 in sources except as a transparent workaround for broken systems. While you could do the workaround in Busybox, I think it would be much more useful as a patch to the Bionic headers that anyone can apply to the installed headers to fix them, and a patch to send upstream to get the source of the problem fixed. > Bionic does *not* implement the 64-bit stdio functions, but those > use a different type (fpos_t instead of off_t) and so are not > affected by this patch. > > Would you be more willing to apply this patch if I were to produce a > unit test suite demonstrating that 64-bit file syscalls work with > off_t while stdio functions remain 32-bit with fpos_t? That's something of a mischaracterization. The only useful stdio functions use off_t: fseeko and ftello. fgetpos and fsetpos are rather useless since all they can do is save/restore a position you've already reached as an abstract position object. They cannot work with any kind of sequential addresses. As for being willing to apply the patch, it's not my decision. Rich _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
