[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