[PATCH 2/7] df: Use statvfs instead of non-standard statfs

[Waldemar Brodkorb]

Hi,
Ralf Friedl wrote,

> Eugene Rudoy wrote:
> >just wanted to point out that besides making the code more portable
> >the change suggested by James has another positive side effect. It
> >eliminates the need for the uClibc related and as of now unreliable
> >workaround added in the second hunk of e184a88 [1].
> >
> >Why unreliable? "statfs s"-variable is allocated on stack and is not
> >initialized (=zeroed) at all, neither on the caller nor on the callee
> >side. So the workaround works only in those cases where the stack (by
> >chance) contain zeros (bytes corresponding to f_frsize would be
> >enough).
> >
> >For the sake of completeness... The problem the code tries to
> >workaround could (as of now) be observed only on mips. See mips
> >specific libc/sysdeps/linux/mips/bits/statfs.h [2]. It contains
> >f_frsize in all its statfs* structs but doesn't signal it by defining
> >_STATFS_F_FRSIZE like e.g. libc/sysdeps/linux/common/bits/statfs.h [3]
> >does. This in turn results in libc/misc/statfs/statfs64.c [4] ignores
> >the field and doesn't copy it (like the comment to the workaround
> >states).
> >
> >statvfs doesn't have this problem, it always sets f_frsize (s. [5]).
> I just want to point out that while uClibc statvfs does always set f_frsize,
> currently on MIPS at least it doesn't use the value returned by the kernel,
> instead it copies the value from f_bsize, thus negating commit https://git.busybox.net/busybox/commit/coreutils/df.c?id=8f4faa1e3db91fc7b50d633e6f9b2f04bf978bb2
> Additionally, the uClibc implementation always calls stat() on the supplied
> argument and for older kernel at least reads /proc/mounts, calls stat() on
> the entries and tries to determine the mount flags that statvfs returns but
> df doesn't use.
> 
> What about using statfs and adding a define to platform.h to determine
> whether the value returned by statfs contains f_frsize?
> To support the buggy implementation in uClic, f_frsize must be set to zero
> before the call and tested later, because it is left unmodified.

May be somebody can suggest a patch to fix the bug in uClibc?
I am always open for bugfixes.

best regards
 Waldemar