[cffi-devel] cffi-sys::default-encoding returns nil on clisp/mingw
Running CLISP on my system with the newtypes branch, I find that the CFFI-SYS::DEFAULT-ENCODING function is returning NIL. Some poking around reveals that CUSTOM:*FOREIGN-ENCODING* is set to #<ENCODING CHARSET:CP1252 :DOS> I looked at the symbol values for everything in the :charset package, and they all specify :UNIX instead of :DOS and so that's what CFFI-SYS::*ENCODINGS* and CFFI-SYS::*CLISP-ENCODINGS* get populated with. So I can see why DEFAULT-ENCODING is returning NIL. Before I head over to clisp-devel and ask about this, I just wanted to see whether this situation surprises anyone here, or if you think it might be a CLISP build configuration issue (which would be funny because I'm one of the MingW package maintainers), or ??? 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? This is on WinXP SP2, CLISP 2.41 (mingw special) with nothing related to encoding for command-line arguments. -- Jack Unrue
"Jack Unrue" <jdunrue@gmail.com> writes:
So I can see why DEFAULT-ENCODING is returning NIL. Before I head over to clisp-devel and ask about this, I just wanted to see whether this situation surprises anyone here, or if you think it might be a CLISP build configuration issue (which would be funny because I'm one of the MingW package maintainers), or ???
Hmm, it's somewhat strange, I guess. BTW, should we worry about line terminator conversions?
This is on WinXP SP2, CLISP 2.41 (mingw special) with nothing related to encoding for command-line arguments.
I've applied a fix and a regression test for this. Should work now, though I haven't tested on windows. Thanks for the bug report. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
On 3/16/07, Luís Oliveira <luismbo@gmail.com> wrote:
BTW, should we worry about line terminator conversions?
The code I write that needs CFFI is UI-related, so I'm not really affected by EOL conversion in that context[1]. Maybe folks that have to interact with databases or HTTP are more sensitive to it.
I've applied a fix and a regression test for this. Should work now, though I haven't tested on windows.
Thanks for the bug report.
Thank you for the fix, it works great here. -- Jack Unrue [1] I do have to worry about EOL chars embedded in string values for certain GUI functions to work in the desired way, but I don't have any code that uses CFFI and does stream I/O.
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.
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
participants (3)
-
Hoehle, Joerg-Cyril -
Jack Unrue -
Luis Oliveira