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
