Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.programming Subject: Re: little-endian Date: Sun, 18 Nov 2012 21:33:03 +1300 Lines: 57 Message-ID: References: <2f491c75-8fbc-4dca-9abe-f11e784454a2@googlegroups.com> <87r4ntp4b1.fsf@informatimago.com> <87mwygpolg.fsf@informatimago.com> <7otfa8pfb07sn1ao039nlfc9cr351h2vtr@4ax.com> <1d8xuw93lwnxy.14j0ojrkbbe4e$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net elK0aJ8Z8A9lZjLx2bsvjwfZpRrqAqPLvnws0dj/Ds4eee9bgd3AB3ny6phFplRs/x Cancel-Lock: sha1:VeNhWhYMSWvqzrAGKmk6dB371cw= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:12.0) Gecko/20120423 Thunderbird/12.0 In-Reply-To: <1d8xuw93lwnxy.14j0ojrkbbe4e$.dlg@40tude.net> Xref: csiph.com comp.programming:2503 On 11/18/12 21:13, Dmitry A. Kazakov wrote: > On Sun, 18 Nov 2012 15:17:51 +1300, Ian Collins wrote: > >> On 11/18/12 11:22, BGB wrote: >>>> Some more valid criticisms of the hton*/ntoh* functions are that they >>>> only support one byte order on the "network" side, support only a >>>> couple of sizes, and only support unsigned values. >> >> long long version are a simple extension. > > Nope. Well the machine I'm typing this on has ntohll and htonll. > It could be middle-endian. On the wire? >> The signed or unsigned nature >> of the type isn't relevant for byte ordering. > > How so? Byte ordering is about encoding things into a byte stream. Signed > integers must be encoded too. Bytes are bytes, whether they represent a signed or unsigned (or even floating point) type is irrelevant. If it were, there would be a bigger common set of byte order reversal functions. >>> far more common I think is to implement file-readers more like: >>> int MyFile_ReadInt32LE(FILE *fd) >> >> The reason for using the common byte ordering functions is to avoid >> having to care about the ordering on the wire (or in a file). > > There are far more types of objects than unsigned integers. When > implementing an application protocol on top of some octet or bit stream > these must be encoded and decoded (serialized/deserialozed) too. There is > nothing special in unsigned integers. Did I say there was? > Usage of functions like hton* should be depreciated unless the protocol > specification explicitly states that the given unsigned integer object is > in the "network" format as implemented by hton*. Which oddly enough, they often are. The whole point of "network byte ordering" is to provide a common standard representation. > It is always cleaner to provide a fair implementation of the protocol, > which could be done in a portable way as BGB described. Which is really the > recommended way. A rare exception might be when you have a library that > already implements the protocol layer of interest completely. It's good to know I've been doing things wrong all these years.... -- Ian Collins