uncompressed size of .gz file
steve at holdenweb.com
Mon Sep 20 20:28:42 CEST 2004
Heiko Wundram wrote:
> Am Montag, 20. September 2004 13:58 schrieb Steve Holden:
>>As long as the format is documented itr doesn't really matter whether it
>> stores the bytes big-endian, little-endian or alternating from the big
>>and little ends.
> I know that. But it's just a rule of thumb for me: take any format which tries
> to be machine indepent, look at the byte-order: big-endian. For example:
> JPEG, TIFF (which has a marker for little or big-endian, but you'll mostly
> find big-endian TIFFs), network addresses, all binary RPC protocols I know
> of, etc.
> It's not that I don't believe the effbot, but I just found it fishy to be
> little-endian when the format is standardized as a HTTP transport encoding
> (which is a network protocol)...
> Wait, I just reread the comment from the RFC... And this clearly states:
> "All multi-byte numbers in the format described here are stored with the
> least-significant byte first (at the lower memory address)."
> least-significant byte first to me sounds like big-endian, doesn't it? And
> thus should warrant a > qualifier, or not? Or am I plain wrong on this?
[Sorry about the delay, I'm forced to access the list rather than the
newsgroup]. On of the laughable things about the names "big-" and
"little-endian" is that unlike their originals (taken from "Gulliver's
Travels", and used to describe which end of a boiled egg should be
opened for eating) they don't actually specify what they mean. This
underlines the essentially arbitrary nature of the choice.
You might as well say "left-handed" or "right-handed"!
XXX Please note recent change of email address
More information about the Python-list