Hoehle, Joerg-Cyril wrote:
Jack Unrue wonders:
For instance, can anyone point me at a spot in the CLISP manual that states that *FOREIGN-ENCODING* will always correspond to the value of one of the symbols in the :charset package?
Quite to the contrary. When linked with the iconv library, you can also use any encodings provided by that library. The encoding name would then be a string.
I've never heard of anyone making use of that feature. People are typically satisfied with the many encodings that clisp ships.
Perhaps I misread you. Above, I'm talking about ENCODING-NAME, which yields a symbol from the CHARSET package in typical cases. Were you asking whether (LOOP/ITERATE FOR s IN-PACKAGE "CHARSET" THEREIS (eq (symbol-value s) *foreign-encoding*)) ? That's a false assumption, as the user may set the *-ENCODING* variables to any value of (ext:make-encoding ...)
It was the issue of what values the user can bind to *-ENCODING* vs an assumption that CFFI was making previously. You addressed what I was really after.
BTW, don't be fooled by the way that the encodings found as SYMBOL-VALUE in package CHARSET claim :LINE-TERMINATOR :UNIX, even on MS-DOS systems. The FFI and ext:convert-string-to/from-bytes never performs a CRLF translation. Only the streams do, when talking to files, sockets or pipes (not string-streams).
Thanks, that is good to keep in mind.