bug#18051: 24.3.92; ls-lisp: Sorting; make ls-lisp-string-lessp a normal function?

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> I think everything in str_collate starting with the "Convert byte
> stream to code pointers." comment (btw, I guess you meant "code
> points" here) should be in a separate function, and the best place for
> that function is sysdep.c.  At least on MS-Windows, both the part that
> converts a Lisp string into wchar_t array, and the part that performs
> a locale-sensitive string comparison, will be implemented differently.

Well, I've moved (most of) str_collate to sysdep.c.

> Thanks.  (You didn't attach the new patch.)

Oops. Appended this time.

> Btw, I wonder whether we should have a way to pass the locale string
> explicitly, instead of relying on $LC_COLLATE.

We could add an optional argument to string-collate-*. But this would
break signature equivalence with string-lessp and string-equal,
respectively.

Or we could introduce a global var, which shall be let-bound to the
locale string.

>> I have added also configure checks HAVE_NEWLOCALE, HAVE_USELOCALE and
>> HAVE_FREELOCALE for the respective glibc functions. I don't know whether
>> it is overengineering, and whether I could simply apply the existing
>> HAVE_SETLOCALE check. I believe all these functions do exist in parallel
>> in locale.h, don't they?
>
> I'll defer to glibc experts on that.  My knowledge of 'newlocale'
> facilities is limited to what I saw in Guile's i18n.c module.

According to the manpages, setlocale is conforming to "C89, C99,
POSIX.1-2001". {new,use,free}locale are conforming to "POSIX.1-2008".
So we must check for HAVE_USELOCALE, indeed. Checks for HAVE_NEWLOCALE
and HAVE_FREELOCALE are not necessary, the functions exist in parallel
to uselocale (introduced in glibc 2.3).

This raises the question, whether we shall use also my first setlocale
approach in case of uselocale absence?

Best regards, Michael.

collate-patch
Description: Text Data