uncompressed size of .gz file

[Steve Holden]

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?
> 
> Heiko.
> 
> 
[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"!

regards
  Steve

-- 
XXX Please note recent change of email address