[ CC:d to cffi-devel, in case the FFI experts have any opinions on external-format handling. ]
Yaroslav Kavenchuk kavenchuk@jenty.by writes:
I have impudence to offer dear community patch for non-ascii encoding of alien c-string once again.
(Maybe me have forgotten? :)
Thanks. There are some issues with this patch.
* On non-windows platforms we need to naturalize a string to find out the default external format, and after this change we need to know the default external format to naturalize a string. But that's easy to fix.
* Also, the patch can't be used stand-alone, since other SBCL internals (e.g. pathname handling) assume that a c-string alien type will be naturalized to a simple-base-string. What's the right thing to do here? Add a new alien-type that does the conversion, and leave c-string as-is, or change to change the behaviour of c-string?
* I'm not sure that the interface is quite right. It seems probable that at one point or another somebody will need to use multiple external formats at once (ebcdic for pathnames and latin-1 for a database connection, or something). So we might need to be able to parametrize the external format to be used when defining the types. As a silly example:
(define-alien-routine strdup (c-string :external-format :latin-1) (str (c-string :external-format :utf-8)))
(Hmm... maybe using a keyword parameter for this is excessive, and an optional would do).
James, Luis, would something like this be useful for CFFI? Would the proposed interface work for you? Any opinions on the c-string issue mentioned above?
A patch implementing this functionality (including Yaroslav's work): http://jsnell.iki.fi/tmp/alien-again.diff