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

Previous Next

Full log

Message #131 received at 18051 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 18051 <at> debbugs.gnu.org
Subject: Re: bug#18051: 24.3.92; ls-lisp: Sorting;
 make ls-lisp-string-lessp a normal function?
Date: Fri, 22 Aug 2014 16:23:34 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>  . I suggest to factor out the part that converts to wchar_t, sets up
>    the locale, and calls strcoll.  The code you wrote makes certain
>    assumptions about 'setlocale', and also about the wchar_t
>    representation.  Factoring those system-dependent parts out will
>    minimize the number of #ifdef's needed to provide such features for
>    other platforms.

I see. But I don't know how to factor out. Shall I move str_collate to
another file? Or to a new file? Something else?

>  . I think glibc has a 'newlocale' API that is better suited to this
>    kind of jobs.  In particular, 'setlocale' changes the locale of the
>    entire program, which is bad news for other threads that might be
>    using some locale-aware functions while the main thread calls
>    string-collate-lessp.  (We have more than 1 thread in Emacs built
>    with GTK, for example, and who knows what those threads might be
>    doing?)

OK, done.

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?

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.