From Arthur Snoke's response:
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:
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
... I don't agree with your statement that the byte order cannot beThe reason Arthur's tactic works is because SAC always writes SGF files
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?
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 routinesMacSAC does not have this bug. Not because it is as clever as Brian's
and this needs to be fixed.
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