Re: [Distutils] [Python-3000] sizeof(size_t) < sizeof(long)
Greg Ewing wrote:
When you go into a computer store and ask for 256MB of RAM, you don't expect to be asked "What size bytes would that be, then, sir?"
I ask for "256 Mo", Mo for Mega-octet: French (and most non English languages I am aware of) does not have this ambiguity :) And anyway, in a computer store, you find memory for personal computers, where one byte always has 8 bits.
So it's a de facto standard, and one that works perfectly well. Going against it is both futile and unnecessary, as far as I can see.
Going against the C standard seems pretty futile to me. cheers, David
David Cournapeau wrote:
I ask for "256 Mo", Mo for Mega-octet: French (and most non English languages I am aware of) does not have this ambiguity :)
But would you ask for it that way in an English-speaking country? Would they have a clue what you were talking about? Anyway, I don't think it really is an ambiguity in practice -- only in the minds of those that have too much time to read standards documents.
And anyway, in a computer store, you find memory for personal computers, where one byte always has 8 bits.
Does it? Or...
Going against the C standard seems pretty futile to me.
Hmmm. So as long as I program my computer in C, it has 8 bit bytes... or at least a C implementation with 8-bit chars. But if I use a special Unicode-C with 16-bit chars, I've then got half as many bytes of memory as I had before... So I have to tell the guy in the computer shop what programming language and implementation I'm using, too! :-) Seems to me that disregarding this particular quirk of the C standard is a lesser evil than confusing everybody by changing the meaning of byte all the time. [In attempt to pull this very slightly closer to being on-topic... what does this imply for the Python bytes type? Are they always 8-bit bytes, or are they whatever size your C compiler thinks bytes are? Do the Python docs need to clarify this?] -- Greg
participants (2)
-
David Cournapeau -
Greg Ewing