At Tue, 28 Sep 2004 07:36:08 -0400, Dave Mason wrote:
>
> On 17 Sep 2004, at 22:33, Alex Shinn wrote:
>
> > an alternative would be to have three sets of procedures with no
> > optional argument:
> >
> >   read-<int>  ; native
> >   read-be-<int> or read-network-<int>
> >   read-le-<int>
>
> a) Presumably those would be slightly faster implementations (with
> read-<int> being one or other of read-be-<int> or read-le-<int>).

I originally figured a fast implementation is likely to inline the
primitives, and with a static 'big-endian or 'little-endian there
would be no difference.  Also with higher-level procedures it's more
convenient to take and pass on an endian argument than to have two (or
three) versions of every binary procedure.  I would only seriously
consider the separate procedures if compiler writers insisted it were
a worthwhile gain.

> b) Given some of the other discussion on the list (see bear's comments
> on the ubiquity of the Internet), I wonder if it is optimal to have 3
> ways to do it.  The reasoning is to *strongly* encourage people to
> write portable, network aware, code.

And force a performance hit on all big-endian machines?  Please read
[HOLY] from the bibliography :)

> The first approach would be to provide *only* read-be-<int> and
> read-le-<int>, possibly named read-net-<int> and read-swapped-<int>

It is common to have a binary format which includes the endian type in
its header or magic, and you want to then think in terms of the endian
and pass it on to utilities, so explicitly naming big-endian and
little-endian is a useful mnemonic.

> The second approach would be to provide read-<int> and read-net-<int>,
> where the read-<int> does the local thing, and read-net-<int> does the
> portable (B.E.) thing.

This makes handling the above file types impossible, and so could not
be a consideration at all.

--
Alex