[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: USGS SDTS - revisited
Mark Hadfield wrote:
> "Kelly Dean" <firstname.lastname@example.org> wrote in message
> > This program was developed under Windows 2000, so if you try this on a
> > UNIX machine, the keyword /Swap_Endian will need to be removed from the
> > Open statements. The /Swap_Endian keyword should remain for Linux and
> > VAX users.
> Note that OPEN supports SWAP_IF_BIG_ENDIAN and SWAP_IF_LITTLE_ENDIAN
> keywords that can be used to make code like this fully portable. They were
> introduced in version 5.1.
I don't see how this would make the code _fully_ portable - unless you were always sure that the
input datfiles were always produced on a particularly-endian-ed machine.
A quick and dirty portability fix is to put the swap_endian keyword in the call - it will save the
user from having to edit the file.
A better way would be for the code itself to determine the endian-ness. Liam Gumley has mentioned
this a number of times in this newsgroup (see his binary read/write tools for an example). I do this
sort of thing all the time now. The only "impediment" is determining what needs to be read from a
file for endian testing. Is there any number in these DEM files that one could be certain of the
value and/or range? E.g. in some aircraft interferometer data I had to read (sometimes generated on
a PC-OS/2 system, sometimes on an IBM RS-6000 or SGI IRIX system) I always checked the band number
(1, 2, or 3) If the numbers weren't 1, 2, or 3 (byte-swapped they were 16777216, 33554432, and
50331648) then I would close the file and re-open with swap_endian set. The code could then read
files created on either little- or big-endian machines within IDL running on either little- or
I wish it was this easy (and as fast) to byte swap data in Fortran (compiler switches don't count).
Paul van Delst Ph: (301) 763-8000 x7274
CIMSS @ NOAA/NCEP Fax: (301) 763-8545
Rm.207, 5200 Auth Rd. Email: email@example.com
Camp Springs MD 20746