uncompressed size of .gz file
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
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