[cffi-devel] cffi-sys::default-encoding returns nil on clisp/mingw
Hoehle, Joerg-Cyril
Joerg-Cyril.Hoehle at t-systems.com
Wed Apr 18 08:54:15 UTC 2007
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 ...)
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).
Regards,
Jörg Höhle.
More information about the cffi-devel
mailing list