Started: 2005-11-21 23:09:16
Last activity: 2005-11-21 23:09:16
Topics: SAC Developers
Brian Savage
2005-11-21 23:09:16

It sounds like whatever we decide, the file formats (SAC and SGF) need
to be documented.

Concerning SGF. If it has always written the files in the same way, why
change it, make it the standard and document it.

Concerning SAC. If we decide all SAC files should be in big endian
format (or even little) I am certain there will be an outcry from the
community who uses Sac for processing and as a data file format. If we
specify an endianness, we are introducing more bugs on linux machines as
they will not be able to read current sac files which are written in
little endian.


George Helffrich wrote:
From Arthur Snoke's response:

... 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?

The reason Arthur's tactic works is because SAC always writes SGF files
with a stanza that writes:

bufsize: 16
color: 7
line: 1
hwsize: 0.013 0.020 1 7
color: 7

There is nothing to prevent an internal change in SAC that would not
write these commands in this order; if SAC were to flush its internal
buffer later than it does, the magic word at the front would have a
value different from 5.

Because there isn't anything in the SGF specification that requires this
buffer be exactly this size and written in that order, the endianness of
an SGF file cannot be reliably determined.

Next, Brian Savage's response:

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

MacSAC does not have this bug. Not because it is as clever as Brian's
proposal for SAC's handling of readhdr/writehdr, but because all files
that MacSAC reads or writes are big-endian. If we specify an endianness,
there is no bug to be fixed.

George Helffrich


sac-dev mailing list

19:13:28 v.d4df61ad