[Toybox] df.c patch and POSIXLY_CORRECT

Rich Felker dalias at libc.org
Mon Nov 24 22:40:29 PST 2014


On Tue, Nov 25, 2014 at 12:02:18AM -0600, Rob Landley wrote:
> Digging through the backlog of patches Ashwini Sharma sent, I'd prefer
> not to apply one particular gnusim in the df.c patch: I'm not a fan of
> the "POSIXLY_ME_HARDER" environment variable check.
> 
> http://en.wikipedia.org/wiki/POSIX#Controversies
> 
> If we want our behavior to match posix even when nobody else does, we
> can change the behavior. If we want to have a different behavior and
> document the deviation, we can do that (and that's what we currently
> do). If we want a compile time "be stupid when posix says something
> stupid/obsolete" kconfig option, we can do that too. But at runtime, I
> prefer consistent behavior. (You an also alias "df" to "df -P", the way
> people alias --color into ls.)
> 
> Doing what posix says to do when people don't _expect_ that has been
> filed as a bug before:
> 
> https://bugs.tizen.org/jira/browse/TC-1787
> 
> I can do TOYBOX_STRICT_POSIX compile time option if people think that's
> a good idea. As one big global switch disabling sed -i and putting cpio
> in 6 byte mode incompatible with all modern uses, breaking tar into
> near-uselessness, disabling half the commands... (If this seems silly,
> how is testing it at runtime instead of at compile time any less of a
> can of worms? I've already _got_ CONFIG_DF_PEDANTIC...)
> 
> Anybody feel like standing up and defending POSIXLY_CORRECT? (While
> _not_ doing an LSB_CORRECT?)

In this case I'm fairly indifferent to it, but runtime requestable via
a well-known mechanism is a lot better than a compile-time option. IMO
it's really bad to have the basic behavior (rather than the set of
available options) of the standard utilities depend on a compile-time
setting.

> P.S. Part of the df patch does:
> 
>    if (CFG_DF_PEDANTIC && (toys.optflags & FLAG_P)) {
> -    xprintf("%s %lld %lld %lld %lld%% %s\n", device, size, used, avail,
> -      percent, mt->dir);
> +    xprintf("%s% *lld % 10lld % 10lld % 7lld%% %s\n", device, len,
> +        size, used, avail, percent, mt->dir);
> 
> Except the posix standard itself currently says:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/df.html
> 
>   The remaining output with -P shall consist of one line of information
>   for each specified file system. These lines shall be formatted as
>   follows:
> 
>   "%s %d %d %d %d%% %s\n", <file system name>, <total space>,
>       <space used>, <space free>, <percentage used>,
>       <file system root>

This is not a printf format string. In XCU documentation of utility
output formats, the printf-like format specifiers have slightly
different meaning. There is no intent in %d that the field be limited
to the range of the type int.

> I varied that to use 64 bit values instead of 32 bit ones (because in
> 2013 POSIX still thinks partitions max out at 2 gigs), but the reason I
> didn't insert spacing is the standard said _not_ to, and -P mode is
> posix. Adding POSIXLY_CORRECT and then adding non-posix spaces to the
> output is just confusing...

Using the full 64-bit values (or whatever size off_t might be) is the
correct POSIX behavior here. I'm not sure about the spacing.

Rich

 1416897629.0


More information about the Toybox mailing list