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
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
