On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt <mich...@freepascal.org> wrote:
> It does not resolve a regression. Yes, it does and I showed it here. > The current behaviour is a bugfix for a reported bug. And it did that the wrong way. Calling Utf8Decode on a string without checking it is indeed Utf8 encoded is plain and simply wrong. I may be totally wrong here, but form the discussion with you I get that you find the String <-> UnicodeString conversions are wrong, because they can cause data loss with strings not encode as UTF8. On the other hand you argue that "The use case of a non-lazarus command-line application is so minor that this can wait for a proper solution for unicode." The combination of these arguments does not make sense to me. Lazarus programs will not suffer from dataloss in the String<->UnicodeString conversions, because all strings in Lazarus are UTF8 encoded. The sample program in the bugreport that lead to this mess (https://bugs.freepascal.org/view.php?id=32185), would also have been solved without the Utf8Decode/Utf8Encode (the sample program is a Lazarus GUI program, so it includes the Lazarus Utf8-hack). AFAICS cutting out the Utf8Decode/Utf8Encode fixes a regression and does not introduce a new regression: all this when compared to behaviour in 3.0.4. The net result of all of this discussion is that I am getting frustrated. -- Bart _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel