Date: Sat, 05 Sep 1998 15:05:57 -0400 (EDT) From: Simon Shapiro <shimon@simon-shapiro.org> To: Eivind Eklund <eivind@yes.no> Cc: freebsd-alpha@FreeBSD.ORG, John Birrell <jb@cimlogic.com.au> Subject: Re: Help - No htonq, ntohq Message-ID: <XFMail.980905150557.shimon@simon-shapiro.org> In-Reply-To: <19980905171747.45786@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Eivind Eklund, On 05-Sep-98 you wrote:
> 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.
Thanx! Am I to understand that what I want does not exist? I saw a
reference to something in /usr/include/nfs/xdr_subs.h but am not clear what
value it has. I'd rather have some concensus first.
Simon
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980905150557.shimon>