Does FFI support WideStrings?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Does FFI support WideStrings?

Mariano Martinez Peck
 
Hi. Someone pointed out here: http://stackoverflow.com/questions/5212790/unicode-characters-in-a-smalltalk-ffi-call-to-opendbx/
a problem while using WideStrings with FFI. FFI throws a "Could not coerce arguments".  Is this because of the usage of WideString?
what we should use instead (I know that ByteString works) ?  can we fix FFI so that it supports WideStrings?

thanks

Mariano
Reply | Threaded
Open this post in threaded view
|

Re: Does FFI support WideStrings?

Levente Uzonyi-2
 
On Sun, 6 Mar 2011, Mariano Martinez Peck wrote:

(pine still can't quote your mail)

FFI doesn't map WideStrings to C strings, because there's no unified way
to do it. What you have to do is to encode the WideString to a
ByteString (using a TextConverter), but you should consult the OpenDBX
manual about this.


Levente
Reply | Threaded
Open this post in threaded view
|

Re: Does FFI support WideStrings?

Henrik Sperre Johansen

 
On Mar 6, 2011, at 10:35 04PM, Levente Uzonyi wrote:

> On Sun, 6 Mar 2011, Mariano Martinez Peck wrote:
>
> (pine still can't quote your mail)
>
> FFI doesn't map WideStrings to C strings, because there's no unified way to do it. What you have to do is to encode the WideString to a ByteString (using a TextConverter), but you should consult the OpenDBX manual about this.
>
>
> Levente

http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_query

"The statement stored in the stmt parameter must be a valid statement understood by the receiving database server and it should be terminated by a \0 character. Some backends support multiple statements per query, which can be tested by calling odbx_get_option().

The length parameter must contain the length of the statement in bytes without the terminating \0 character. If variable sized character sets like UTF-8 are used, the same rule applies. This function doesn't support the wide character type (wchar_t) which uses two or four bytes per character. If you feed 0 (zero) as length parameter to the function, it will calculate the size of the statement on its own."

Sooooo...
It's guess it's pretty much up to the user to figure out how to use the right encoding for the backend in question.

From the POV of providing a low-overhead solution, I guess that is an ok decision, and at least it's honest about it.
From a user POV though, it's a pretty strong argument for switching to an API which handles it transparently :)

I mean, why on earth would use use an abstract interface if you have to know intricate details about how to access each backends encoding in order to do queries/pass strings correctly?

Cheers,
Henry