On Sunday, 26 April 2015, at 10:28 pm, Rich Felker wrote: > On Sat, Apr 25, 2015 at 04:06:23PM -0400, Matt Whitlock wrote: > > 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.
The Bionic headers aren't broken. _FILE_OFFSET_BITS is a convenience provided by Glibc, but it is not specified by any standard. If you think it's a bad idea to map off_t to off64_t within BusyBox, then another option would be to define a bb_off_t type that is equivalent to off_t when compiling without _LARGEFILE64_SOURCE or else equivalent to off64_t when compiling with _LARGEFILE64_SOURCE. There would be similar definitions of bb_lseek(), bb_pread(), bb_pwrite(), bb_ftruncate(), and other LFS functions in the future, as Bionic implements them. The changeset necessary to switch BusyBox to using this new type and these new functions would be rather expansive, and (in my opinion) it seems undesirable to make such an unintuitive change just to support one flavor of libc. I will submit a patch to the Bionic devs to add support for _FILE_OFFSET_BITS, but frankly I don't expect much cooperation by them, and even if they do apply the patch, it would only affect new versions of Bionic. There is no reason BusyBox can't have large file support on older versions of Bionic as well. Passing the buck upstream consigns support for large files in BusyBox to the future when BusyBox could easily have such support now. > > 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. > > 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. Point taken. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
