size in kbytes?

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Hi,

I allocate some memory of size_t but want to express:

printf("Total amount of allocated memory is: %lu bytes.\n", (unsigned
long) total_mem);

in kilo-bytes. So is method 1 or 2, the correct one? I've seen both
explanations using google:

1)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned long)
total_mem/1024);

2)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned long)
total_mem/1000);



Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Hi,

I allocate some memory of size_t but want to express:

printf("Total amount of allocated memory is: %lu bytes.\n", (unsigned
long) total_mem);

in kilo-bytes. So is method 1 or 2, the correct one? I've seen both
explanations using google:

Depends on your definition of kilobyte
http://en.wikipedia.org/wiki/Kilobyte

 

[stathis gotsis]

Hi,

I allocate some memory of size_t but want to express:

printf("Total amount of allocated memory is: %lu bytes.\n", (unsigned
long) total_mem);

in kilo-bytes. So is method 1 or 2, the correct one? I've seen both
explanations using google:

1)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned long)
total_mem/1024);

2)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned long)
total_mem/1000);

In data storage context the prefix K usually equals 1024, while in network
transfer context it may equal 1000. The prefix Ki is set to 1024, so 1 KiB =
1024 bytes.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Depends on your definition of kilobyte
http://en.wikipedia.org/wiki/Kilobyte

What would you use and why? What's "normal" ?

I think 1024 is more correct...?


Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

What would you use and why? What's "normal" ?

If you're producing harddrives or other storage it's "normal" to
use 1000.

I think 1024 is more correct...?

I think so too. I'd use 1024, and the suffix KiB instead
of KB or kilobyte.

 

[Eric Sosman]

Hi,

I allocate some memory of size_t but want to express:

printf("Total amount of allocated memory is: %lu bytes.\n", (unsigned
long) total_mem);

in kilo-bytes. So is method 1 or 2, the correct one? I've seen both
explanations using google:

1)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned long)
total_mem/1024);

2)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned long)
total_mem/1000);

Method #2 is correct[*]. The International System of Units (SI)
defines the prefix "kilo" to mean multiplication by one thousand,
hence, the conversion from bytes to kilobytes (or volts to kilovolts,
or manjaros to kilomanjaros) requires dividing by one thousand.
See <http://physics.nist.gov/cuu/Units/prefixes.html>.

[*] Since your code performs an integer division, any fractional
part will be truncated. For example, 1024 bytes will be reported as
one kilobyte, rather than 1.024 kilobyte. Whether this truncation is
"correct" or not depends on the use to which the result is put.

Method #1 is traditional among computer geeks, who noticed long
ago that 1024 is not terribly different from 1000. Since the number
1024 cropped up often enough in computerdom to make a convenient
abbreviation desirable, the geeks co-opted the prefix "kilo" to mean
multiplication by 1024. This was the Original Sin, from which has
flowed much grief.

... because computers grew larger, and pretty soon the geeks
needed a convenient way to express multiplication by 1048576, two
to the twentieth. With the evil precedent of "kilo" already in
place, it was easy for them to sin again and abuse "mega" in a
similar fashion. "Giga" followed, and then "tera," and "peta"
has begun to pop up -- in the last year, I've even seen "zetta"
abused, skipping right over "exa." SI defines "zetta" to mean
multiplication by 1,000,000,000,000,000,000,000 (ten to the 21st),
while in geekery it multiplies by 1,180,591,620,717,411,303,424
(two to the seventieth).

Notice how the Original Sin has become worse with the passage
of time and the growth of the numbers. The misuse of "kilo" causes
an error of 2.4%, about one part in forty-two (the significance of
the denominator is left as an exercise for the hitchhiker). By
co-opting "mega" the geeks magnified the error to 4.9%, one part
in twenty-one. "Giga" is off by 7.4% (one part in fourteen), and
by the time the geeks have gored "zetta" they're off by a whopping
18% (one part in six). This proves that computer people have no
interest in accuracy. (It has long been said that mathematicians
are people who can't add, while computer programmers are people
who can't even count.)

Does the inaccuracy cause trouble? Yes! At a PPOE I was doing
last-minute bug-fixing before product release, and one of the Q/A
people reported a bug in the installation phase. The documentation
said installation required X megabytes of available disk space, so
the Q/A engineer decided to make sure it would actually work. He
filled a disk with garbage files until only X megabytes of free
space remained, then tried to install. The installation failed for
lack of sufficient space, and the Q/A engineer filed a bug. I'm sure
you can see where this is going: the documentation (and the install
program) wanted X * 1048576 bytes, while the disk on the test machine
had only X * 1000000 bytes available. Yes, Virginia, a 4.9% error
can make a difference.

The oddest and perhaps most bletcherous abuse in this sad history
of wilful corruption is the "1.44 megabyte" floppy disk. Said disk
does *not* hold 1.44 megabytes using either the true SI "mega" or
the geekish two-to-the-twentieth "mega." What is actually holds is
1.44 "kilo" (SI) "kilobytes" (geekish), a truly bastardized unit
unloved by both parents.

The International Electrotechnical Commission has made a noble
attempt to extend an olive branch to the geeks by standardizing
a set of prefixes for binary multipliers: kibi, mebi, gibi, ...
(See <http://physics.nist.gov/cuu/Units/binary.html>.) The geeks,
however, are an ungracious and ungrateful lot and have spurned this
peace offering; they continue to misuse "kilo" et al. for their own
dastardly purposes. They are in agreement with Humpty Dumpty, who
said "When I use a word it means just what I choose it to mean."
Such an attitude evidences a certain independence, perhaps, but also
a lack of interest in communicating.

When all those geeks find themselves condemned to a few megayears
in Purgatory for their prefix abuse, let's be sure to ask them how
they'd like "mega" defined, shall we?

 

[Richard G. Riley]

Depends on your definition of kilobyte
http://en.wikipedia.org/wiki/Kilobyte

And in memory terms, it is reasonably safe and proper to use 1024 as
the equivalent amount.

 

[Skarmander]

Hi,

I allocate some memory of size_t but want to express:

printf("Total amount of allocated memory is: %lu bytes.\n", (unsigned
long) total_mem);

in kilo-bytes. So is method 1 or 2, the correct one? I've seen both
explanations using google:

1)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned
long) total_mem/1024);

2)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned
long) total_mem/1000);

Method #2 is correct[*].

<snip>

Damn, and we were this close to skipping the off-topic flamewar material.
People even gave a link for self-education.

> When all those geeks find themselves condemned to a few megayears
> in Purgatory for their prefix abuse, let's be sure to ask them how
> they'd like "mega" defined, shall we?
>

May you be hurled into the sun at one attoparsec per microfortnight[*].

S.
[*]Caveat lector: not an SI unit.

 

[Eric Sosman]

Skarmander wrote On 03/30/06 11:28,:

Eric Sosman wrote:

When all those geeks find themselves condemned to a few megayears
in Purgatory for their prefix abuse, let's be sure to ask them how
they'd like "mega" defined, shall we?

May you be hurled into the sun at one attoparsec per microfortnight[*].

S.
[*]Caveat lector: not an SI unit.

Geez, that's harsh! All I did was invent a new unit
called the "manjaro," a quantity equal to the carcase of
one leopard found above the snow line ...

 

[Jordan Abel]

Hi,

I allocate some memory of size_t but want to express:

printf("Total amount of allocated memory is: %lu bytes.\n", (unsigned
long) total_mem);

in kilo-bytes. So is method 1 or 2, the correct one? I've seen both
explanations using google:

1)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned long)
total_mem/1024);

2)
printf("Total amount of allocated memory is: %lu kb.\n", (unsigned
long) total_mem/1000);

Method 1 probably meets user expectations better, and will be more
consistent with the way other tools on most systems express amounts of
memory. And, actually, you should use "B", not "b" for bytes, "b" is
bits. Probably the best solution is to write "KiB" and use 1024.

 

[Jordan Abel]

Does the inaccuracy cause trouble? Yes! At a PPOE I was doing
last-minute bug-fixing before product release, and one of the Q/A
people reported a bug in the installation phase. The documentation
said installation required X megabytes of available disk space, so
the Q/A engineer decided to make sure it would actually work. He
filled a disk with garbage files until only X megabytes of free
space remained, then tried to install. The installation failed for
lack of sufficient space, and the Q/A engineer filed a bug. I'm sure
you can see where this is going: the documentation (and the install
program) wanted X * 1048576 bytes, while the disk on the test machine
had only X * 1000000 bytes available. Yes, Virginia, a 4.9% error
can make a difference.

But when you hit "properties" on the disk drive, it will tell you the
amount of free space in units of 1048576 bytes. Your "trouble" is
imagined, and you're QA engineer is an idiot. Incidentally, it is
impossible to predict _exactly_ the amount of space that will be needed,
to the byte, because the size of each file is rounded up to an unknown
[well, known, but varies by system and even by drive] power of two, and
directories also take up space, so the whole attempt is flawed, and it
would probably have failed anyway.

Say what you will about the 1024-based units, but with the SOLE
exception of the number printed on the box that the drive comes in, it's
internally consistent.

 

[Keith Thompson]

What would you use and why? What's "normal" ?

Did you have a question about the C programming language?

 

[Eric Sosman]

Jordan Abel wrote On 03/30/06 12:39,:

But when you hit "properties" on the disk drive, it will tell you the
amount of free space in units of 1048576 bytes. Your "trouble" is
imagined, and you're QA engineer is an idiot.

Mr. Abel, you may insult me all you like, because
I'm here to defend myself or ignore you or cave in to
your onslaught as I deem proper. Hurling names like
"idiot" at a conscientious Q/A engineer whom you've
never met or exchanged a word with is another matter.

For the record, the system in question reported
available disk space in units of bytes. I was there;
you were not.

Also for the record, there's a difference between
"you're" and "your." Learn the difference and apply
your knowledge, and your prose will gain an appearance
of authority. Perhaps.

Incidentally, it is
impossible to predict _exactly_ the amount of space that will be needed,
to the byte, because the size of each file is rounded up to an unknown
[well, known, but varies by system and even by drive] power of two, and
directories also take up space, so the whole attempt is flawed, and it
would probably have failed anyway.

Mr. Abel, I was there; you were not. When I gave the
installation procedure the X * 1048576 bytes it wanted, lo!
the product installed just fine. So much for "probably
would have failed anyway."

For the record, the system in question did not round
file sizes up to powers of two.

Say what you will about the 1024-based units, but with the SOLE
exception of the number printed on the box that the drive comes in, it's
internally consistent.

Herein you are right: A mis-measurement is consistent
with itself. However, he who calibrates a meter stick by
measuring it against itself does surprisingly little to
advance the cause of knowledge.

 

[Randy Howard]

Nils O. Selåsdal wrote

If you're producing harddrives or other storage it's "normal" to
use 1000.

Solely as a result of lying marketing departments within those
companies. Besides, that has more to do with with Megabyte and
Gigabyte mangling than kilobytes. I don't recall even one hard
drive marketed with a capacity in kilobytes in the last 20
years.

I think so too. I'd use 1024, and the suffix KiB instead
of KB or kilobyte.

Why? KiB seems far less well-known than either of the other
two.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Method 1 probably meets user expectations better, and will be more
consistent with the way other tools on most systems express amounts of
memory. And, actually, you should use "B", not "b" for bytes, "b" is
bits. Probably the best solution is to write "KiB" and use 1024.

Strange, because you know: I believe that I tried many programs on
various systems over the years... And AFAIR I can't think of one single
program using "KiB" for output. Therefore I won't use "KiB" - I guess
there are people out there who don't even know what KiB is. I still
don't know whether to use 1024 or 1000, but I think I'll write KB after
the number...


Best regards / Med venlig hilsen
Martin Jørgensen

 

[Richard G. Riley]

Does the inaccuracy cause trouble? Yes! At a PPOE I was doing
last-minute bug-fixing before product release, and one of the Q/A
people reported a bug in the installation phase. The documentation
said installation required X megabytes of available disk space, so
the Q/A engineer decided to make sure it would actually work. He
filled a disk with garbage files until only X megabytes of free
space remained, then tried to install. The installation failed for
lack of sufficient space, and the Q/A engineer filed a bug. I'm sure
you can see where this is going: the documentation (and the install
program) wanted X * 1048576 bytes, while the disk on the test machine
had only X * 1000000 bytes available. Yes, Virginia, a 4.9% error
can make a difference.

Sounds more like there was simply not enough temp space for the
workings of the install process. Or did the QA guy, incorrectly, use
1000 as 1 k? Which is, of course, incorrect in all HD/RAM standards for
any system I have ever used.

 

[Skarmander]

Strange, because you know: I believe that I tried many programs on
various systems over the years... And AFAIR I can't think of one single
program using "KiB" for output.

I'm not surprised. "KiB" was introduced in 1999 and is only slowly gaining
momentum. I have seen it once or twice in programs, but I'll probably never
hear someone pronounce it. Although, you never know.

Therefore I won't use "KiB" - I guess there are people out there who
don't even know what KiB is.

Well, unless context is clearly provided, people won't know what (or rather
how much) KB is either, so in comparison that's a relatively minor problem.

I still don't know whether to use 1024 or 1000, but I think I'll write KB
after the number...

This exact attitude will definitely put you in alignment with the mainstream
approach.

S.

 

[Jordan Abel]

Jordan Abel wrote On 03/30/06 12:39,:

Mr. Abel, you may insult me all you like, because
I'm here to defend myself or ignore you or cave in to
your onslaught as I deem proper. Hurling names like
"idiot" at a conscientious Q/A engineer whom you've
never met or exchanged a word with is another matter.

What reaction did this QA person get from the programmers who wrote the
installer?

For the record, the system in question reported
available disk space in units of bytes. I was there;
you were not.

Unless it reported available space in units of 1000000 bytes, it was
still not a bug.

Also for the record, there's a difference between
"you're" and "your." Learn the difference and apply
your knowledge, and your prose will gain an appearance
of authority. Perhaps.

It was a typo.

Incidentally, it is impossible to predict _exactly_ the amount of
space that will be needed, to the byte, because the size of each file
is rounded up to an unknown [well, known, but varies by system and
even by drive] power of two, and directories also take up space, so
the whole attempt is flawed, and it would probably have failed
anyway.

Mr. Abel, I was there; you were not. When I gave the
installation procedure the X * 1048576 bytes it wanted, lo!
the product installed just fine. So much for "probably
would have failed anyway."

It's possible that it rounded its result up. It _is_ impossible to know
it exactly, because it can depend on whether directories in the
installation path already existed, what block size the filesystem uses
[you deny it uses one at all, but i'd like proof if you really think
that], and any number of other factors.

For the record, the system in question did not round
file sizes up to powers of two.

To _any_ power of two? Your filesystem is apparently magic.

a 1-byte file doesn't take up 512 bytes or more on disk? What about
space needed for its filename, etc, in the directory? Does a file with
a name seven letters long take a byte less on disk than one with a name
eight letters long? If you have a million 1-byte files, that will only
take a megabyte, or, at least, will take a megabyte less space than
a million 2-byte files? I seriously doubt that.

Herein you are right: A mis-measurement is consistent
with itself. However, he who calibrates a meter stick by
measuring it against itself does surprisingly little to
advance the cause of knowledge.

And he who complains that a meter stick is 9.3% longer than a yard, and
that you should report yards as meters to accomodate people using the
imperial system, does even less. 1000000-byte megabytes are as
out-of-place on computers as feet, yards, and miles are elsewhere.

 

[David Resnick]

What reaction did this QA person get from the programmers who wrote the
installer?

Sounds like a good QA guy to me. He read the requirements and
constructed a test based on his reading of them. If you believe
that no reasonable end users (and many end users are not
reasonable) would interpret the documentation as the QA guy did,
well, I think you are wrong. I've had bugs assigned to me by
QA I thought were based on bizarre reading of requirements docs,
but this one wouldn't make me blink. No call to say he is an idiot.

-David

 

[Pedro Graca]

I still
don't know whether to use 1024 or 1000, but I think I'll write KB after
the number...

Your best option would be to let the user decide:

/* read config values from initialization file, or command line
* switches, or environment variables. */
config->user.unitsize = 1728;
config->user.unitdesc = " great gross bytes";

/* ... */

printf("Total amount of allocated memory is: %lu%s.\n",
(unsigned long) mem / config->user.unitsize,
config->user.unitdesc);