Thread: byte order and swapping

George,

Just picking up on a detail in your note:

By accident, there is a reliable way to tell the endianness of a SAC
data file due to the known format of the data file header. However,
there is no analogous way to tell what the endianness of a SAC SGF file
is reliably. So the present situation provides a workable, yet
complicated solution for SAC data, but none for SGF.

As you probably recall, I have worked quite a bit with SGF format, having
decided 10+ years ago to use that for my graphics format for just about
everything. I don't agree with your statement that the byte order cannot
be discerned easily for SGF files. The first "word" in an SGF file is a
4-byte integer which is (using od -t -d2 on the Sun) 00000 00005 for big
endian and 01280 00000 on PC/Linux. Am I missing something?

I have planned to write a SGF translator, but it is always next on my to-do
list. Part of the problem is that it is a pain because everything is I*2
except the first word in each command which is I*4. I know how to do it,
but it is a bit tedious. I have written a set of subroutines which can
write .sgf files without using any SAC library routines for both endians
and my sgf2ps works on both platforms (and is a part of the SAC
distribution). From the notes on your variant on SAC, you have many
additions which I would like to see worked into the formal SAC
distribution, and would be happy to work with you on that.

This is a sideline on your main point: how to deal with endians in sac
data files. You say that it is trivial to tell the endian of a sac data
file. But part of the problem which Chuck brought up at our meeting at
the IRIS workshop is that one could have a header with one endian but the
data in the other by using READHDR/WRITEHDR on the platform with the
opposite endian from which the file was created. Again, am I missing
something?

Arthur

There appears to be two camps concerning this. Either way, we need to
make a decision about byte order and create the read and write routines
to handle them.

At present we still have a problem with the readhdr/writehdr routines
and this needs to be fixed.


My own personal opinion is this. When sac was developed it used the
native format for Sun (Big endian) and this was fine. Livermore had not
decided if big endian was the standard format and thus moving to the
linux (little endian format) allowed for sac files to be in another byte
order. Allowing for two different formats is the easiest and least
instrusive thing to do. Not to be rude, but I think Livermore has
inadvertently made our bed for us.

Swapping massive amounts of data or rewriting software to conform to a
standard introduced part way into the game is something none of us would
like to do. Do not force others to do it.

Brian


George Helffrich wrote:

The byte-swapping/header rewriting issue highlights a problem that SAC
still has, to wit:
there is no specification as to what the byte order in SAC files is.

By accident, there is a reliable way to tell the endianness of a SAC
data file due to the known format of the data file header. However,
there is no analogous way to tell what the endianness of a SAC SGF file
is reliably. So the present situation provides a workable, yet
complicated solution for SAC data, but none for SGF.

If we decide, as a community, this endianness issue, then the issues
with byte-swapped headers vs data disappears. The only reason it exists
is because we never have answered the endianness question.

So why not specify it?

Based on the historical fact that SAC was developed on Ridge and Sun
machines -- both big-endian -- there is an argument for files being
big-endian. However, both Macs and PCs are converging towards
little-endian order, so a more practical choice might be little.

Does anybody object to or disagree with the need to specify a byte order?


George Helffrich

_______________________________________________
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev