Subject: [clisp-list] ext:convert-string-to-bytes ignores the encoding's :line-terminat or

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Jan 27 08:02:02 2003

Hi,

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 ... :line-terminator :dos
 -> 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 yourself!

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

Regards,
	Jörg Höhle.