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
