[PATCH] Bionic lacks transparent LFS migrations; provide a workaround

Rich Felker dalias at libc.org
Wed Apr 29 02:54:37 UTC 2015


On Tue, Apr 28, 2015 at 03:55:59PM -0400, Matt Whitlock wrote:
> On Tuesday, 28 April 2015, at 9:56 am, Rich Felker wrote:
> > What I do think is a bad idea is providing a hackish environment where
> > only some things work correctly with 64-bit off_t and others silently
> > fail or even misinterpret their arguments and blow up. If that can be
> > avoided and the ugliness can be contained in a pit that's isolated to
> > Bionic, I'm not opposed to it.
> 
> For what it's worth, BusyBox *presently* misinterprets arguments on
> Bionic because Bionic's struct stat has 64-bit st_ino and st_size,
> but BusyBox happily assigns the values of these fields into
> variables of type ino_t and off_t, which breaks at run-time. These

Uhg.

> problems would be apparent at compile-time too, except that
> BusyBox's build system doesn't specify -Wconversion, so no warnings
> are produced. Specifying -Wconversion reveals numerous places
> throughout the BusyBox sources where rvalues are implicitly
> narrowed. My personal belief is that these warnings should always be
> enabled, and implicit narrowing conversions should always be avoided
> by using explicit casts, to make obvious that a change in value is
> possible, but I am not here to convince the BusyBox devs to
> eliminate all the implicit narrowing conversions in BusyBox.

The implicit narrowing warnings are almost all noise. For instance any
arithmetic with types smaller than int will result in implicit
narrowing when you store the result. So I don't think it's practical
to use them.

> Besides, I agree that Bionic is at fault for deviating from the
> standard here by declaring st_ino and st_size as unsigned long long
> and long long rather than as ino_t and off_t.

Yes, this is very broken. This all really needs to be fixed on
Bionic's side -- they should drop the support for 32-bit off_t and
always remap the standard names (at the header level) to the *64
functions. It would have been better if they'd never defined the
non-64-suffixed functions with the wrong 32-bit-off_t semantics to
begin with but that mistake was already done. Still they can fix the
compile-time behavior without breaking their ABI.

> I'll work on finishing the Large File Support in Bionic and adding
> support for _FILE_OFFSET_BITS==64. Is there any chance that a Bionic
> headers patch could be shipped with BusyBox? Again, there is no
> reason to require BusyBox users to compile against the latest Bionic
> headers just to get support for large files. In fact, LFS could be
> implemented on all versions of Bionic with a simple "-include" in
> CFLAGS. (That's almost no different than implementing it in
> platform.h, but maybe you'd like it better in a separate file.)

For Busybox in the short term, I'd say just use whatever works well
and doesn't uglify non-Bionic support. But considering how broken this
is there should really be a push to fix Bionic in a way all apps can
use, not just Busybox. Whether that means upstreaming a patch to fix
it or having a patch/preinclude that you can just apply/add to CFLAGS
probably depends on what's practical with upstream...

Rich


More information about the busybox mailing list