home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!decwrl!pa.dec.com!engage.pko.dec.com!e2big.mko.dec.com!nntpd.lkg.dec.com!news!benoy
- From: benoy@alpha.aosg.gsf.dec.com (Benoy Desouza AOSG)
- Newsgroups: comp.sys.dec
- Subject: Re: ALPHA OSF1 xdr problem
- Message-ID: <1993Jan25.155039.1341@aosg.gsf.dec.com>
- Date: 25 Jan 93 15:50:39 GMT
- References: <WARREN.93Jan20172646@stormy.atmos.washington.edu>
- Sender: usenet@aosg.gsf.dec.com (USENET News System)
- Organization: AOSG
- Lines: 24
- Nntp-Posting-Host: alpha.aosg.gsf.dec.com
-
- In article <WARREN.93Jan20172646@stormy.atmos.washington.edu>,
- warren@atmos.washington.edu (David Warren) writes:
- |> Has anyone successfully used xdr routines on an alpha for reading or
- |> writing longs. The ALPHA doesn't seem to know that a long by xdr
- |> definition is only 32 bits. I am trying to build the UNIDATA netcdf
- |> library (scientific data format) which uses xdr format. It is trying
- |> to use the xdr library that comes with the ALPHA and the tests fail
- |> because the ALPHA can't get longs correct.
- |> --
-
- xdr_long() on OSF/1 Alpha DOES adhere to the internet RFC 1014 (XDR)
- and is really xdr_int() (just like ntohl() on OSF/1 Alpha is really a
- network-to-host-int). Beware that if you declare a variable as a long
- on OSF/1 Alpha, you will be getting a 64 bit integer. Hence if you try
- to xdr_long() this 64 bit quantity, you would not get the same results
- as on a 32 bit OS. You should really be applying xdr_long() ONLY to
- "ints" on OSF/1 Alpha.
-
- -------------------------------------------------------------------
- Benoy DeSouza AOSG (OSF/1 Alpha)
- Mailstop: GSF1-1/K13 (dtn) 264-5877
- Digital Equipment Corp. (external) (603) 884-5877
- 5 Wentworth Drive enet: benoy@aosg.gsf.dec.com
- Hudson, NH 03051 decnet: alpha::benoy
-