Well, to my thinking , in C 'string' defined as 'a sequence of characters (bytes) terminated by zero byte'. 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" ;) But sure thing, i am not opposed to having a really nice encoding/decoding schemes, which you can easily control. On 5 July 2013 15:45, Henrik Johansen <[email protected]> wrote: > I just had a glance at Nix/Win32Environment NB calls, and nearly cried... > (context: > http://www.youtube.com/watch?v=Um41DPPs5ZA&list=SP843D1D545F9F52B6&index=15&t=1619 > ) > > Which got me thinking, maybe an extra opt (possibly non-static, ref database > libraries string encodings) if Strings are expected as parameters should be > mandatory, for specifying the expected encoding of the library being called? > (oh yes, MANDATORY, if you don't know what is required, you shouldn't be > passing in Smalltalk strings in the first place) > > You'd then be able to cut out ALL the manual cruft in the video's > getEnvironmentVariableW: wrapper call basically needed for any current call > to a method accepting Strings. > (assuming you're not ok with mysterious failures once parameter/return is > outside ascii range) > > Might it work with a few choice assembly implementations of encoders (utf8 + > utf16) along the lines of NBUTF8StringExample (expanded to handle both Wide- > and ByteString arguments/returns), as well as a fallback (or just) using > callback which employs in-image converters? > (Such a preamble would also be a good place to do embedded 0 character checks > for args expected to be c strings: > http://www.hakipedia.com/index.php/Poison_Null_Byte) > > This have some other implications as well of course; > -NBExternalAddress readString/writeString should be removed or made encoding > aware. In the current form, they are dangerous/useless outside of pure ascii… > - How to handle char * parameters. Perhaps parameter-specific validity checks? > a) NBExternalAddress - Assume correctly manually encoded contents if > allowExternalAddressOpt or whatever its called is set? > b) ByteArray - Assume correctly manually encoded contents? > c) String - Same as above, either encoding opt set, or return error > 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) > Cheers, > Henry > > -- Best regards, Igor Stasenko.
