Wow, I'm nappy! :)
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.
Excuse me, I do not have *nix.
May be use :latin-1 to naturalize string with external format?
> * 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
I suggest to replace [simple-]base-string to [simple-]string for all
pathnames and alien functions calls with c-string.
Patch for win32 is attached.
> * 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:
I do not think, that various encodings are necessary for a call of one
alien function. But even in this case it is possible to use later
transformation from (* (unsigned 8)) to c-string.
> (define-alien-routine strdup (c-string :external-format :latin-1)
> (str (c-string :external-format :utf-8)))
Nice (for future)
> (Hmm... maybe using a keyword parameter for this is excessive, and
> an optional would do).
With keyword parameter more readably (IMHO)
WBR, Yaroslav Kavenchuk.