Date: Sat, 5 Sep 1998 17:17:47 +0200 From: Eivind Eklund <eivind@yes.no> To: John Birrell <jb@cimlogic.com.au>, shimon@simon-shapiro.org Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Help - No htonq, ntohq Message-ID: <19980905171747.45786@follo.net> In-Reply-To: <199809042227.IAA12990@cimlogic.com.au>; from John Birrell on Sat, Sep 05, 1998 at 08:27:40AM %2B1000 References: <XFMail.980904181025.shimon@simon-shapiro.org> <199809042227.IAA12990@cimlogic.com.au>
index | next in thread | previous in thread | raw e-mail
On Sat, Sep 05, 1998 at 08:27:40AM +1000, John Birrell wrote:
> Simon Shapiro wrote:
> > Can anyone suggest a clean, portable way to support binary competability on
> > 64bit integers between an Alpha and IA?
>
> int64_t & u_int64_t
>
> > We have hton{l,s} but these are good only for 16 & 32 bit values.
>
> I think hton{l,s} should be kept strictly for _network_ code.
I think Simon is working on sharing binary data between Intel and
Alpha (running with shared disk). Saying 'strictly for network code'
doesn't help solve the problem at all. May I suggest the introduction
of
hton16s(l,s) ntoh16s(l,s)
hton16u(l,s) ntoh16u(l,s)
hton32s(l,s) ntoh32s(l,s)
hton32u(l,s) ntoh32u(l,s)
hton64s(l,s) ntoh64s(l,s)
hton64u(l,s) ntoh64u(l,s)
as a much more clear way of handling the naming? (I placed the
sign-indicator after the number of bits, to avoid confusion with
htons()). This also give a clear answer to the question 'what should
I use for 64-bit' :-)
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980905171747.45786>