[sac-dev] byte order and swapping

[Arthur Snoke]

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