[Fwd: Re: [sac-dev] byte order and swapping]

[Brian Savage]

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.

Brian




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
> no-op:
> 
> 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
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev