Quoth Eric Lowe on Thu, Oct 19, 2006 at 12:56:07PM -0500:
> Yann POUPET wrote:
> >Maybe I'm wrong, but I think we can distinguish 2 cases:
> >
> >- the base (base-2 or base-10) is choosen according to user's preferences :
> >If we display a number of bytes for example, some user may prefer to see
> >them displayed in base-2 (1K for 1024 bytes), some other may prefer to
> >see them displayed in base-10 (1.024K for 1024 bytes)
>
> I really don't think this is a preference the user should be able to
> set. There is no precedent for doing this, and there doesn't seem to be
> any value either since radix-2 is really only used when displaying bytes
> for historical (and horrible) reasons.
I disagree. Aren't harddrive capacities advertised in base-10? Might
it not make my life easier to be able to tell my tools to report sizes
in base-10? (See 5008336.)
That said, it should be up to the tool to allow the user to make this
choice. The function should accept an argument (like proposed) and not
use an environment variable.
Extra credit if all such tools used the same mechanism, e.g.,
a particular environment variable.
> >This does not fix the suffix problem, and I still don't know how it
> >could be managed; maybe another ENV var to choose between ('K','M','G'
> >...) and ('Ki', 'Mi', 'Gi', ...) ? Maybe a silly idea ...
We should always use Ki... for base-2. This will reduce ambiguity and
user confusion.
> There is an easy way out of the suffix problem: use 'b?' for K, M, etc.
> and 'b?i' for Ki, Mi, ... so I don't see why there is so much debate
> about this. Forcing KiB, MiB, etc. will forcibly change the output of
> tools which currently display KB, MB, etc. using 2**(10**n) which may be
> undesirable.
No, it is desirable. Are there tools which have declared that their
output with scaled numbers is stable? Even if there are, they don't
have to be converted to use this function. All new code should be
forced to use suffixes which indicate the base. Let's fix the world.
David
