the above is CLISP's documented behaviour, nevertheless I've got a =
feeling that it's wrong.
o Write to a stream :element-type 'character :external-format ... =
-> CRLF is written out for each #\newline
o write to a stream :element-type '(unsigned-byte 8) using =
EXT:CONVERT-STRING-TO-BYTES because for some reason, you can't work =
with CLISP's character streams (lack of bivalence).
-> <LF> is written out for each #\newline
That is, if you want to use :element-type '(unsigned-byte 8), you have =
to split the strings into separate lines and insert all CR and/or LF =
OTOH, the current behaviour is consistent with the 1:1 restriction of =
the FFI: the foreign side only sees a single LF for each #\newline when =
FFI:C-STRING is used as a parameter or return type specification.
I'm wondering what is seen on a Mac.
Consistency with FFI means that (unix:ffi-write ... (c-array character =
type) ...) and (ext:write-byte-sequence (ext:convert-string-to-bytes =
#)) write the same thing: no CRLF, only LF.
The current behaviour makes it much less straightforward to roll one's =
own stream doing 8bit I/O.
Maybe that's a limitation of the internal mbs_*() library?
IMHO it would be nice to emulate CLISP's CR/LF conversion for character =
streams using convert-string-to-bytes.
The thing is: convert-string-to-bytes already takes a required =
:encoding argument. Why not use the :line-terminator embedded in that =