On Tue, Feb 26, 2019 at 10:49 AM Marco van de Voort <c...@pascalprogramming.org> wrote:
> If I look into e.g. registry.pp, the only use of utf8encode there is > like this: > > var s : string; > > u:unicodestring; > > s:=utf8encode(u); > > which, IF lazarus is used in the default utf8 mode is equivalent to > > > s:=u; > > So currently this utf8encode only frustrates the situation for people > that don't set the default codepage to utf8? Exactly. It also breaks backwards compatibility. Strings returned were encode in the systems codepage up to 3.0.4, now thy are not. There will be programs out there that access individual chars of those returned string parameters, and they will now fail for any character that is not lower ascii (7-bit ascii). Also it makes no sense to return strings in UTF8 and not require input strings to be encoded the same. The argument that reading a string is now unicode proof also makes no sense to me, since, unless your systemcodepage is UTF8, there is no way to write a unicode character back to registry. If we need that, we need overloaded methods with either Utf8String or UnicodeString parameters. I don't mind leaving the registry functions using plain ansistrings, but then let go of the idea it could support Unicode if your systemcodepage is not UTF8. B.t.w. enforcing UTF8 on the results rather complicates the code for returning a TStringList. -- Bart _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
