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

[Juho Snellman]

[ CC:d to cffi-devel, in case the FFI experts have any opinions on
  external-format handling. ]

Yaroslav Kavenchuk <kavenchuk at 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

-- 
Juho Snellman