[cffi-devel] cffi-sys::default-encoding returns nil on clisp/mingw

[Jack Unrue]

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.

-- 
Jack Unrue