On Jul 5, 2013, at 4:59 , Igor Stasenko wrote:
Well, to my thinking , in C 'string' defined as 'a sequence of characters (bytes) terminated by zero byte'. Yeah, except, you know, most/all libraries do not really deal with theoretically pure C strings, and we certainly when passing in "a string" from Smalltalk. In practice, we're dealing with passing/converting Smalltalk strings to functions expecting a pointer to bytes in a certain encoding. (either null-terminated or with an additional size arg)
There is nothing about encoding, because it is related to text, but C 'string' can be something else than human-readable text and contain anything and used for different purpose.
From that perspective, if strictly following such definition, i do not see how you can force encoding to be a mandatory part of it. (except from having special encoding, named "NO_ENCODING" ;)
And from that perspective, any user will *never* create safe bindings to/from anything but ASCII ByteStrings by default. FFI, meet 1988. And even those who do, have to jump through an excessive amount of hoops, ref https://dl.dropboxusercontent.com/u/6751081/Environment.zip
But sure thing, i am not opposed to having a really nice encoding/decoding schemes, which you can easily control.
The caveat is that options is applicable to whole callout's generated code. What if i have function which takes 2 arguments: - string with utf-8 encoding - string with utf-16 encoding
so, you cannot put that in options, because you need to control it on a per-argument basis.
The only way i see how to do that is same as in NBUTF8StringExample: you explicitly designate the type of argument e.g.
void foo(utf8String x, utf16String y)
No, not for FFI you don't. Any sane external library will never use different encodings for string parameters to the same method. In fact, I challenge you to find *any* which doesn't. Cheers, Henry