GNOME Bugzilla – Bug 512443
Incorrect unit abbreviations in gslice docs and g_format_size_for_display
Last modified: 2008-09-15 15:17:40 UTC
The documentation for gslice and implementation of g_format_size_for_display use incorrect unit abbreviations. They operate using powers of two, but claim to use powers of 10. Other information: There has been discussion on the mailing lists about what type of unit g_format_size_for_display should use. Although there has been no conclusion as to which should be used, it is plainly wrong to use the abbreviation of one for the values of another.
Created attachment 103836 [details] [review] Properly label units in g_format_size_for_display and docs of gslice Use binary prefixes (KiB, MiB, etc) rather than decimal prefixes when working with binary values. Does not change at all the actual values used.
The mailing list thread is here http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00237.html I'm firmly in the "traditional units" camp on this, so don't expect me to approve this patch. The strings are translatable, so you can just start your own en_US.si-units locale variant...
> I'm firmly in the "traditional units" camp on this, so don't expect me to > approve this patch. The strings are translatable, so you can just start your > own en_US.si-units locale variant... If a function prints the length of a kilometer as "1000 feet", the solution is to correct the function, not monkeypatch it with translations.
The fact that "kilo" is the SI prefix for "1000" does not automatically entail that a "kilobyte" is "1000 bytes". Language is not a formal system, it's just a set of conventions. And the convention in the English language has been, for the past several decades, that "kilobyte" and "kb" mean "1024 bytes". As long as the majority of the English-speaking world continues to use those definitions (eg, Dell and HP still advertise "1 GB" machines that have 1073741824 bytes of RAM), no one has the authority to simply assert that those definitions are wrong.
I agree with Matthias (as can be seen from gslice.c) and the majority of replies on the mailing list seems to do as well, so I'll close this bug accordingly.
*** Bug 550203 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > The fact that "kilo" is the SI prefix for "1000" does not automatically entail that a "kilobyte" is "1000 bytes". Of course it does. You could use 'kilobyte' to mean '67 monkeys' in your software, but that doesn't change the definition of the terms. You're just using them incorrectly. > Language is not a formal system, it's just a > set of conventions. But this *is* a formally-defined system. These prefixes are part of an international standard of measurement prefixes that is already ingrained into users from everyday life. "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits)." http://www.bipm.org/en/si/si_brochure/chapter3/prefixes.html > And the convention in the English language has been, for > the past several decades, that "kilobyte" and "kb" mean "1024 bytes". Not with any consistency, and it has since been officially deprecated anyway. I was taught that "K = 1024" in a computing class in the 80s, too. That doesn't mean it was right, or even a good idea. This convention is illogical and completely unfamiliar to the majority of modern users. The trend in Free Software is to use consistent, common sense units to prevent user confusion. When we display file sizes to end-users, we should use the standard unit prefixes that they are familiar with; k- = 1,000, M- = 1,000,000, etc. http://www.kernel.org/doc/man-pages/online/pages/man7/units.7.html Even if K=1024 were a de facto standard (it isn't), it simply doesn't serve any rational purpose to display file sizes (which can be any arbitrary value) as multiples of 1024. Please re-open this and fix glib.