uncompressed size of .gz file

Heiko Wundram heikowu at ceosg.de
Mon Sep 20 14:36:24 CEST 2004

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?


More information about the Python-list mailing list