Hi all,

When using the cwstring widestringmanager the function AnsiCompareText seems to have a bug.

For example:

{$mode objfpc}{$H+}
uses
  Classes, SysUtils, cwstring;
begin
  writeln('o   and .   gives ',AnsiCompareText('o','.'));
  writeln('oc  and .o  gives ',AnsiCompareText('oc','.o'));
  writeln('oce and .ou gives ',AnsiCompareText('oce','.ou'));
end.

Result:

o and . gives 1
oc and .o gives 1
oce and .ou gives -18

I tested on Linux 64bit with fpc 2.6.2 and 2.7.1 (rev 25875).

See bug report
http://bugs.freepascal.org/view.php?id=25378

What is the state of the cwstring manager?

Mattias

Under Mac OS X 10.5 I get:

o and . gives 33
oc and .o gives 33
oce and .ou gives 33

Under Linux I get the same as you with an UTF-8 locale. With LANG=C, I get "1" as result for each comparison under Linux though.

See bug report http://bugs.freepascal.org/view.php?id=25378 What is the state of the cwstring manager?

Fully functional and supported. It can of course nevertheless contain bugs. This looks more like a potential bug in glibc though, but I'd have to check in more detail to confirm that (for which I don't have time right now).

Jonas

Possibly as intended because the collation of the current locale ignores punctuation.

Martin

You're right: https://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021

So there is no bug in either FPC or glibc. The locale is simply defined like that on Linux.

Jonas

I learned a new thing.
Thank you both!

Mattias

Needs documentation though.

Should I create a bug report?

Mattias