Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I'm seeking for ideas about what to do with encodings in the --without-unicode case. I wish ffi:with-foreign-string to be available without unicode (it still makes sense), and I wonder how to deal with the :encoding keyword and how to treat it.
Currently available in CLISP even without #+unicode
sys::encoding-zeroes -> 1
o CLISP using --without-unicode still knows an ENCODING type
o it has custom:*default-file-encoding* (which is used for its :line-terminator).
o Therefore, convert-string-to/from-bytes could be given that as argument.
1. But what about functions which take optional or keyword arguments. What should they default to?
Should I just use
(&key (encoding #+unicode custom:*default-foreign-encoding*
? This doesn't look like the right thing do me.
Or should I have the low-level C code deal with NIL in the #ifndef UNICODE case and use some internal encoding?
2a. Does cstombs() still work?
2b. Even with a NULL or other possibly unusual encoding argument?
E.g. lispbibl.d:with_string_0() uses that and does not distinguish a #ifndef UNICODE case.
Note that currently, the actual encoding supplied to with-foreign-string in the #-unicode case does not matter, since line-terminator is ignored (as in convert-string-to-bytes). You will never get CRLF out of a #\newline!