Bruno Haible writes:
> Pascal J.Bourguignon wrote:
> > > It seems that clisp always swap bytes, which is wrong of course (on
> > > linux/ppc which is big-endian). But anyways, file format should not
> > > be dependant on the processor
> You're contradicting yourself here: If you say that swapping bytes is
> "wrong", you are assuming that following the processor's endianness would
> be correct. But then the file format would depend on the processor!
> clisp implements the I/O on binary streams in a way that the format on disk
> is _not_ processor dependent. The details are undocumented, but happen to
> be little-endian for types such as `(UNSIGNED-BYTE ,(* 8 n)).
Well, I'm unhappy that the implemented byte order be little-endian
(most portable binary file formats and the Internet protocols use
big-endian), but I can deal with it.
(the choice of endianness is mentioned in this section:
> > > so there should be a mean to specify
> > > the endianness with :EXTERNAL-FORMAT.
> You would gain nothing. There is no specification of the bit-by-bit
> format of a stream of `(UNSIGNED-BYTE ,n) or `(SIGNED-BYTE ,n) integers
> that a CL implementation can produce. Therefore you cannot read such a file
> in a different CL implementation than the one that produced it. And you can
> already read it in the same CL implementation.
> ANSI CL says that "The external-format is meaningful for any kind of file
> stream whose element type is a subtype of character." You see, it's not
> meant for binary I/O.
The complete quote is:
The external-format is meaningful for any kind of file stream
whose element type is a subtype of character. This option is
ignored for streams for which it is not meaningful; however,
implementations may define other element types for which it is
meaningful. The consequences are unspecified if a character is
written that cannot be represented by the given external file
An implementation is free to define :EXTERNAL-FORMAT(s) for other
I was suggesting to do that.
For example instead of defining non-standard EXT:READ-INTEGER and
EXT:WRITE-INTEGER with a :ENDIANNESS argument, one could have rather
defined an implementation specific external format. (I imagine that
this possibility appeared only with the standard and did not exist at
the CLtL epoch).
:EXTERNAL-FORMAT '(:CLISP-BINARY-FILE [:ENDIANNESS [:BIG|:LITTLE]]
[:HEADER T|NIL] ...)
But now I understand that the external format for element types other
than (signed-byte 8) or (unsigned-byte 8) [or rather device native
byte size] are to be considered implementation specific and should not
be used for portable binary file formats.
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.