This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.
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