473,395 Members | 1,556 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,395 software developers and data experts.

size in kbytes?

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

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk
Mar 30 '06 #1
38 1726
Martin Jørgensen wrote:
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
Mar 30 '06 #2
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
news:ra************@news.tdc.dk...
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.
Mar 30 '06 #3
Nils O. Selåsdal wrote:
Martin Jørgensen wrote:
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


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

I think 1024 is more correct...?
Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk
Mar 30 '06 #4
Martin Jørgensen wrote:
Nils O. Selåsdal wrote:
Martin Jørgensen wrote:
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


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.
Mar 30 '06 #5
Martin Jørgensen wrote:
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?

--
Eric Sosman
es*****@acm-dot-org.invalid

Mar 30 '06 #6
On 2006-03-30, Nils O. Selåsdal <NO*@Utel.no> wrote:
Martin Jørgensen wrote:
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


And in memory terms, it is reasonably safe and proper to use 1024 as
the equivalent amount.
Mar 30 '06 #7
Eric Sosman wrote:
Martin Jørgensen wrote:
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.
Mar 30 '06 #8


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 ...

--
Er*********@sun.com

Mar 30 '06 #9
On 2006-03-30, Martin Jørgensen <un*********@spam.jay.net> wrote:
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.
Mar 30 '06 #10
On 2006-03-30, Eric Sosman <es*****@acm-dot-org.invalid> wrote:
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.
Mar 30 '06 #11
Martin Jørgensen <un*********@spam.jay.net> writes:
Nils O. Selåsdal wrote:
Martin Jørgensen wrote:
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


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


Did you have a question about the C programming language?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 30 '06 #12


Jordan Abel wrote On 03/30/06 12:39,:
On 2006-03-30, Eric Sosman <es*****@acm-dot-org.invalid> wrote:
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.


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.

--
Er*********@sun.com

Mar 30 '06 #13
Nils O. Selåsdal wrote
(in article <44********@news.broadpark.no>):
Martin Jørgensen wrote:
Nils O. Selåsdal wrote:
Martin Jørgensen wrote:

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


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

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 1024 is more correct...?

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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Mar 30 '06 #14
Jordan Abel wrote:
On 2006-03-30, Martin Jørgensen <un*********@spam.jay.net> wrote:
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.


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

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk
Mar 30 '06 #15
On 2006-03-30, Eric Sosman <es*****@acm-dot-org.invalid> wrote:
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.
Mar 30 '06 #16
Martin Jørgensen wrote:
Jordan Abel wrote:
On 2006-03-30, Martin Jørgensen <un*********@spam.jay.net> wrote:
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.


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.
Mar 30 '06 #17
On 2006-03-30, Eric Sosman <Er*********@sun.com> wrote:


Jordan Abel wrote On 03/30/06 12:39,:
On 2006-03-30, Eric Sosman <es*****@acm-dot-org.invalid> wrote:
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.


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.
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.


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.
Mar 30 '06 #18
Jordan Abel wrote:
On 2006-03-30, Eric Sosman <Er*********@sun.com> wrote:


Jordan Abel wrote On 03/30/06 12:39,:
On 2006-03-30, Eric Sosman <es*****@acm-dot-org.invalid> wrote:

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.


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?


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

Mar 30 '06 #19
Martin Jørgensen wrote:
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);
--
If you're posting through Google read <http://cfaj.freeshell.org/google>
Mar 30 '06 #20
On 2006-03-30, David Resnick <ln********@gmail.com> wrote:
Jordan Abel wrote:
On 2006-03-30, Eric Sosman <Er*********@sun.com> wrote:
>
>
> Jordan Abel wrote On 03/30/06 12:39,:
>> On 2006-03-30, Eric Sosman <es*****@acm-dot-org.invalid> wrote:
>>
>>> 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.
>
> 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?


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.


It's still not a bug. I hope that the response was to put a clarifying
sentence in the documentation, rather than to change the installer to
use 1000000 instead.
Mar 30 '06 #21
Jordan Abel wrote:
On 2006-03-30, David Resnick <ln********@gmail.com> wrote:
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.


It's still not a bug. I hope that the response was to put a clarifying
sentence in the documentation, rather than to change the installer to
use 1000000 instead.


I believe it is a documentation bug (at least where I work, we can
and do file defects against documentation). I also think it was
maybe a bug not to pad the required disk space a bit more, which
would have made the 4% difference moot, as any other process
mucking with the disk during the install could quite easily push
the thing over the edge.

-David

Mar 30 '06 #22
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
news:s0************@news.tdc.dk...
Nils O. Selåsdal wrote:
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...?


"kilo" officially means 1000; the official prefix for 1024 is "kibi".
However, common use is to use the standard prefixes to mean powers of 2 for
things measured in bytes (except hard drive packaging) and powers of 10 for
things measured in bits. This is officially incorrect, but it's pervasive.

So, Ethernet is 10Mb/s, which is 10,000,000 bits/sec, whereas 16MB of RAM is
16,777,216 bytes. However, a "300GB" hard drive will be 300,000,000,000
bytes (roughly), not the 322,122,547,200 bytes most consumers expect, though
your OS will report the size as 279GB (following common use).

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
Mar 30 '06 #23
On 2006-03-30, Stephen Sprunk <st*****@sprunk.org> wrote:
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
news:s0************@news.tdc.dk...
Nils O. Selåsdal wrote:
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...?


"kilo" officially means 1000; the official prefix for 1024 is "kibi".
However, common use is to use the standard prefixes to mean powers of 2 for
things measured in bytes (except hard drive packaging) and powers of 10 for
things measured in bits. This is officially incorrect, but it's pervasive.

So, Ethernet is 10Mb/s, which is 10,000,000 bits/sec, whereas 16MB of RAM is
16,777,216 bytes. However, a "300GB" hard drive will be 300,000,000,000
bytes (roughly), not the 322,122,547,200 bytes most consumers expect, though
your OS will report the size as 279GB (following common use).

S


To summarize: Don't use "K". If you use "k", use 1000. Don't use 1000.
Use 1024. If you use 1024, use "Ki" and NOT "k". Don't use "b", that
means bits. "%lu KiB",(unsigned long)(x/1024) is the right way, "%lu \
kB",(unsigned long)(x/1000) is the wrong way, and none of the other ways
make any sense at all.

Any disagreement?
Mar 30 '06 #24
On Thu, 30 Mar 2006 14:37:21 -0600, in comp.lang.c , "Stephen Sprunk"
<st*****@sprunk.org> wrote:
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
news:s0************@news.tdc.dk...
Nils O. Selåsdal wrote:
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...?


"kilo" officially means 1000;


indeed. Except in computing, where, since the dawn of time, it has
meant 1024.
the official prefix for 1024 is "kibi".


That is absolutely the very first time I've ever heard anyone claim
that and be serious. I'm aware of the IEC attempt to standardise, but
frankly nobody in the world uses these aburd francisations.

And by teh way given Wikipedia's record on correctness, the only way
I'd rely on it now is if I could cross check against a copy of the
Encyclopedia Britannica...
gd&r

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 30 '06 #25
On 30 Mar 2006 21:36:25 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
To summarize: Don't use "K". If you use "k", use 1000. Don't use 1000.
Use 1024. If you use 1024, use "Ki" and NOT "k". Don't use "b", that
means bits. "%lu KiB",(unsigned long)(x/1024) is the right way, "%lu \
kB",(unsigned long)(x/1000) is the wrong way, and none of the other ways
make any sense at all.

Any disagreement?


Make mine a large one, barman.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 30 '06 #26
Mark McIntyre <ma**********@spamcop.net> writes:
On Thu, 30 Mar 2006 14:37:21 -0600, in comp.lang.c , "Stephen Sprunk"
<st*****@sprunk.org> wrote:

[...]
the official prefix for 1024 is "kibi".


That is absolutely the very first time I've ever heard anyone claim
that and be serious. I'm aware of the IEC attempt to standardise, but
frankly nobody in the world uses these aburd francisations.

And by teh way given Wikipedia's record on correctness, the only way
I'd rely on it now is if I could cross check against a copy of the
Encyclopedia Britannica...
gd&r


Ok, quoting the Britannica article on "byte" (Encyclopaedia Britannica
2006 Ultimate Reference Suite DVD):

Because a byte contains so little information, the processing and
storage capacities of computer hardware are usually given in
kilobytes (1,024 bytes) or megabytes (1,048,576 bytes). Still
larger capacities are expressed in gigabytes (about one billion
bytes) and terabytes (one trillion bytes).

It's true that the metric system claimed the "kilo", "mega", et al
prefixes as powers of 10 before they were used in computing. It's
also true that, in most computing contexts, it's far more useful to
work with powers of 2 than with powers of 10. If there's blame to be
assigned for the resulting confusion, it probably goes to the computer
science folks who started mis-using the existing prefixes.

I did hear 65536-byte memories being referred to as "65K" in the late
1970s; these days, I think they'd almost universally be referred to as
"64K".

The "kibi" "mebi" et al prefixes seem like a reasonable way to deal
with the conflict, but the use of "kilo" for 1024, "mega" for 1048576,
etc., is probably too entrenched to be eliminated -- so we'll probably
just have to deal with the confusion until the end of time.
(Introducing an improved standard in 1999 seems not to be best way to
have it catch on.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 30 '06 #27
On 2006-03-30, Keith Thompson <ks***@mib.org> wrote:
Mark McIntyre <ma**********@spamcop.net> writes:
On Thu, 30 Mar 2006 14:37:21 -0600, in comp.lang.c , "Stephen Sprunk"
<st*****@sprunk.org> wrote:

[...]
the official prefix for 1024 is "kibi".


That is absolutely the very first time I've ever heard anyone claim
that and be serious. I'm aware of the IEC attempt to standardise, but
frankly nobody in the world uses these aburd francisations.

And by teh way given Wikipedia's record on correctness, the only way
I'd rely on it now is if I could cross check against a copy of the
Encyclopedia Britannica...
gd&r


Ok, quoting the Britannica article on "byte" (Encyclopaedia Britannica
2006 Ultimate Reference Suite DVD):

Because a byte contains so little information, the processing and
storage capacities of computer hardware are usually given in
kilobytes (1,024 bytes) or megabytes (1,048,576 bytes). Still
larger capacities are expressed in gigabytes (about one billion
bytes) and terabytes (one trillion bytes).

It's true that the metric system claimed the "kilo", "mega", et al
prefixes as powers of 10 before they were used in computing. It's
also true that, in most computing contexts, it's far more useful to
work with powers of 2 than with powers of 10. If there's blame to be
assigned for the resulting confusion, it probably goes to the computer
science folks who started mis-using the existing prefixes.

I did hear 65536-byte memories being referred to as "65K" in the late
1970s; these days, I think they'd almost universally be referred to as
"64K".

The "kibi" "mebi" et al prefixes seem like a reasonable way to deal
with the conflict, but the use of "kilo" for 1024, "mega" for 1048576,
etc., is probably too entrenched to be eliminated -- so we'll probably
just have to deal with the confusion until the end of time.
(Introducing an improved standard in 1999 seems not to be best way to
have it catch on.)


My solution is to abbreviate it as "Ki" but pronounce it as "kilo" in
the privacy of my own home. And/or abbreviate "KiB" further to "K".
Mar 31 '06 #28
"Jordan Abel" <ra*******@gmail.com> wrote in message
news:sl***********************@random.yi.org...
On 2006-03-30, Stephen Sprunk <st*****@sprunk.org> wrote:
"kilo" officially means 1000; the official prefix for 1024 is "kibi".
However, common use is to use the standard prefixes to mean powers
of 2 for things measured in bytes (except hard drive packaging) and
powers of 10 for things measured in bits. This is officially incorrect,
but it's pervasive.

So, Ethernet is 10Mb/s, which is 10,000,000 bits/sec, whereas 16MB
of RAM is 16,777,216 bytes. However, a "300GB" hard drive will be
300,000,000,000 bytes (roughly), not the 322,122,547,200 bytes most
consumers expect, though your OS will report the size as 279GB
(following common use).


To summarize: Don't use "K". If you use "k", use 1000. Don't use 1000.
Use 1024. If you use 1024, use "Ki" and NOT "k". Don't use "b", that
means bits. "%lu KiB",(unsigned long)(x/1024) is the right way, "%lu \
kB",(unsigned long)(x/1000) is the wrong way, and none of the other ways
make any sense at all.

Any disagreement?


Personally, if it were my code I'd conform to popular usage (kilo=1024)
unless it were in a context where it actually mattered (it almost never
does), and then I'd add a config option for the pedants.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
Mar 31 '06 #29
"Stephen Sprunk" <st*****@sprunk.org> wrote:
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
news:s0************@news.tdc.dk...
Nils O. Selåsdal wrote:
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...?


"kilo" officially means 1000; the official prefix for 1024 is "kibi".


Theoretically. I've never seen them used except by official publications
of engineers' associations and the writings of dorks who think they're
kewl.

Richard
Mar 31 '06 #30
jjf

Mark McIntyre wrote:
On Thu, 30 Mar 2006 14:37:21 -0600, in comp.lang.c , "Stephen Sprunk"
<st*****@sprunk.org> wrote:

"kilo" officially means 1000;


indeed. Except in computing, where, since the dawn of time, it has
meant 1024.


Not true. I started in the industry long after the dawn of computing
time, but the first couple of machines I worked on were widely deployed
commercial systems which had memory counted and addressed in kilobytes
of 1000 bytes, They did their arithmetic in ASCII as well, but that's
another story.

Mar 31 '06 #31
Eric Sosman wrote:
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.


i.e. 2880 512-byte sectors = 1,474,560 bytes
Mar 31 '06 #32
Mark McIntyre wrote:
Except in computing, where, since the dawn of time, it has
meant 1024.


I don't know about that. Or maybe I should say I *do* know about that. I've
been in "the business" since '74 or so, and initially worked with rather older
equipment. More than a few systems I worked with used 1000 for K. In fact, it
was common for us to find out what the documents were using for K and write it
on the cover. I've probably left twenty or thirty manuals behind with notes in
the lower right corner saying either "K=1000" or "K=1024" or (in a few annoying
cases) "K=BOTH."

- Bill
Mar 31 '06 #33
Mark McIntyre wrote:
<st*****@sprunk.org> wrote:
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
Nils O. Selåsdal wrote:

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...?
"kilo" officially means 1000;


indeed. Except in computing, where, since the dawn of time, it
has meant 1024.


That dawn is well within the memory of the present generation.
the official prefix for 1024 is "kibi".


That is absolutely the very first time I've ever heard anyone claim
that and be serious. I'm aware of the IEC attempt to standardise,
but frankly nobody in the world uses these aburd francisations.


And, until relatively recently, nobody used kg, meters, etc. Now,
outside the US, nobody uses the FPS system. The length of Henry
VIIIs arm is no longer an accepted standard.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Mar 31 '06 #34
On 2006-03-31, CBFalconer <cb********@yahoo.com> wrote:
Mark McIntyre wrote:
<st*****@sprunk.org> wrote:
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
Nils O. Selåsdal wrote:

> 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...?

"kilo" officially means 1000;


indeed. Except in computing, where, since the dawn of time, it
has meant 1024.


That dawn is well within the memory of the present generation.


Which present generation? The one that had Apple II's at school and DOS
PCs at home?
Mar 31 '06 #35
On Fri, 31 Mar 2006 11:06:40 -0500, in comp.lang.c , CBFalconer
<cb********@yahoo.com> wrote:
And, until relatively recently, nobody used kg, meters, etc. Now,
outside the US, nobody uses the FPS system.
Come over to the UK sometime, and after you drive the miles from the
airport, someone will buy you a pint of beer, I'm sure.
The length of Henry
VIIIs arm is no longer an accepted standard.


Grin.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 31 '06 #36
CBFalconer wrote:
Mark McIntyre wrote:
<st*****@sprunk.org> wrote:
"Martin Jørgensen" <un*********@spam.jay.net> wrote in message
Nils O. Selåsdal wrote:
<snip>
the official prefix for 1024 is "kibi".

That is absolutely the very first time I've ever heard anyone claim
that and be serious. I'm aware of the IEC attempt to standardise,
but frankly nobody in the world uses these aburd francisations.


And, until relatively recently, nobody used kg, meters, etc. Now,
outside the US, nobody uses the FPS system. The length of Henry
VIIIs arm is no longer an accepted standard.


Never say nobody. I'm outside the US ans still use feet and inches, it's
what I grew up with so it's what I think in most easily. I somehow doubt
I am the only one in the UK still using imperial measurements.

Also, most people miss-use the IS units according to what I was taught
in school. The multiplies should be in upper case and divisors in lower
case. So any time you see "mb" it is a milli-bit not a megabyte, and
"mB" would be a milli-byte. These are probably not the most useful of
measurements.

All this is tremendously off topic, so this will be my only contribution.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Mar 31 '06 #37
Flash Gordon <sp**@flash-gordon.me.uk> writes:
Also, most people miss-use the IS units according to what I was taught
in school. The multiplies should be in upper case and divisors in lower
case.


This is not uniformly true. "k" is a multiplier that should be
lowercase.
--
"Programmers have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_
Mar 31 '06 #38
Flash Gordon wrote:
.... snip ...
Also, most people miss-use the IS units according to what I was
taught in school. The multiplies should be in upper case and
divisors in lower case. So any time you see "mb" it is a milli-
bit not a megabyte, and "mB" would be a milli-byte. These are
probably not the most useful of measurements.


mb and mB are probably quite useful when measuring the performance
of arithmetic compressors :-)

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Apr 1 '06 #39

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
by: Giovanni Bajo | last post by:
Hello, python24.dll is much bigger than python23.dll. This was discussed already on the newsgroup, see the thread starting here:...
11
by: Walter Dnes (delete the 'z' to get my real address | last post by:
I've noticed a few threads (full of sound and fury, signifying nothing) here recently about allocation of large memory blocks. I'm about to start on a personal pet project where I'll be using...
11
by: mike | last post by:
hi, i am running a very big code on my pc using redhat linux. when i try to increase my array size, compile and run, i get segmentation fault. i go into the debugger, run it, it crashes right...
53
by: Neo | last post by:
Hi All, Is that true that size of a byte not necessarily 8-bit? What the std. says? If that true, then what will the size of an int, i mean what sizeof(int) should return? On my machine...
19
by: Jerry | last post by:
I am wondering what is the maximum size of memory that malloc() could handle. Is there any limitation on that? Where am I supposed to get this kind of information? Thank you everybody.
4
by: George Birbilis | last post by:
http://www.support.microsoft.com/default.aspx?scid=kb;EN;q273482 the above speaks for ASP and IIS4, but is it true for the IIS version that comes with Win2000 and with ASP.net? that is, cause...
1
by: Vicky | last post by:
i have specified 10000 kbytes iin maxrequestlength , now if a file having size more than the limit is selected and upload button is pressed then page not found error comes. How to check file size...
4
by: vigori | last post by:
I have an application that send a file to a web service (I built both the application and the web service) I set the max file size via web.config of the web service: <httpRuntime...
4
by: bienwell | last post by:
Hi all, I developed an web page in ASP.NET to upload file into the server. In the Web.config file, I declared <httpRuntime executionTimeout="1200" maxRequestLength="400000" /> The MAX...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.