[cffi-devel] Re: [Sbcl-devel] encoding of alien c-string once again

[Yaroslav Kavenchuk]

Juho Snellman wrote:
> 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.
>   

Fixed (see alien-c-string.patch)

>   * 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?
>   

Partially fixed (see non-ascii-pathnames.patch). Need help on
non-windows platforms.

>   * 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)))
>   

Fixed (see alien-c-string.patch).
(Maybe now redefine utf8-string as (c-string :external-format :utf8)?)


Well, what now?

-- 
WBR, Yaroslav Kavenchuk.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches.tar.bz2
Type: application/octet-stream
Size: 7247 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20060523/9364d86c/attachment.obj>