Zvone wrote:
>> Hi,
>> I uploaded a better Unicode port of TPop3Cli here:
>> http://www.duodata.de/misc/delphi/ics/OverbyteIcsPop3Prot.zip
> Thanks for making a quick fix, I will surely use it and probably a few
> other people here as well. But I'm more for a permanent solution so
> I'll keep an eye on this.

I did not update the source repository since this patch breaks existing
RDS 2009+ apps. It's probably too late to go into v7, though one could 
argue that it fixes a bug and also improves performance?  

> I've been researching a bit and seems that using AnsiChar and
> AnsiString types to store binary data are safe they only have codepage
> associated with them so only conversions may be issue but apart from
> that they should behave binary safe as before in earlier versions of
> Delphi/C++. As long as you assign one AnsiString with the same
> codepage (like system default one, even if it is Japanese locale)
> there should be no conversions. 

That's correct. Using AnsiString for binary data however was dangerous
in older versions too. Whenever the content was interpreted as texual
content by the RTL/VCL. 

> I'm not sure though what would happen
> if two AnsiStrings were in different codepages, then probably some
> conversions may occur but haven't tried that. 

It might be different in C++Builder, in Delphi for example, any 
string passed to procedure Foo(S: UTF8String) will be converted to
UTF8String implicitly if its codepage wasn't CP_UTF8. In order to 
prevent those implicit conversions of ansi strings you have to use 
RawByteString as the parameter type. Passing a UnicodeString to
a parameter of type RawByteString converts it to the default 
AnsiString (with current system ansi codepage). 

Arno Garrels

To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to