Re: bug in join: case comparisons don't work in multibyte locales

[Bruno Haible]

Hi Jim and Pádraig,

> > 1) Which functions to use for case comparison in coreutils?

pb> I think if we're going to do it we should do it right.
pb> I.E. use ulc_casecmp

jm> I prefer the "correct" approach, especially since I believe that will
jm> eventually align with POSIX, even if it doesn't match the current intent
jm> (I don't know).

Thanks, it's good to see we are in agreement here.

> > 2) There is a problem with the case comparison in "sort -f": POSIX specifies
> >    how this option should behave, in terms of the old POSIX terms
> >    ("all lowercase characters that have uppercase equivalents").

pb> c) Always use ulc_casecmp for consistency and assume that's POSIX' intent.

jm> How about a third approach?
jm> 
jm>   Use ulc_casecmp unconditionally (assuming it's available), and resort
jm>   to adding POSIXLY_CORRECT if enough people complain *and* if somehow
jm>   POSIX cannot be changed to accommodate the correct behavior.

Fine with me. Although working towards this with the Austin group will be
another challenge.

> > 3) ... When an executable grows from 35 KB to 175 KB ...
> >      c) Should these Unicode string functions be packaged externally to
> >         coreutils, and coreutils can link to it as an external dependency
> >         (like it does for libiconv, libintl, libacl, etc.)?

pb> That would allow any other non coreutils programs using them to also
pb> share the memory used for the tables. That would be best I think,
pb> but again lots of effort.

jm> c) would be great.  The size issue is non-negligible, even if
jm> it's just four programs.  Besides, I'd like to keep coreutils
jm> out of the shared-library-creation/installation business.

OK, I'll work on the creation of a GNU project called 'libunistring', that
will export the functions from gnulib as a shared library.

Bruno