Hi Marc,
Marc Espie wrote on Mon, Nov 15, 2021 at 05:06:23PM +0100:
> On Mon, Nov 15, 2021 at 03:43:47PM +0100, Jan Stary wrote:
>> On Nov 10 18:46:08, [email protected] wrote:
>>> On Nov 10 18:15:44, [email protected] wrote:
>>>> expr(1) says
>>>>
>>>> expr1 {=, >, >=, <, <=, !=} expr2
>>>>
>>>> Returns the results of integer comparison if both arguments
>>>> are decimal integers; otherwise, returns the results of
>>>> string comparison using the locale-specific collation
Yikes. Yes, that is true in general. Then again, the OpenBSD
C library intentionally supports only one single collation sequence:
POSIX.
>>>> sequence. The result of each comparison is 1 if the specified
>>>> relation is true, or 0 if the relation is false.
>>>>
>>>> Looking at expr.c, it boils down to strcoll(), which ignores the locale.
>>>> So the statement is technically true, but there isn't really any
>>>> "locale-specific collation sequence".
>>>>
>>>> Would it be simpler to leave the mention of locale completely out?
Yes, probably, and then add a CAVEATS section warning that on other
operating systems, the collation order may vary depending on the
LC_COLLATE environment variable.
>>>> Or state something similar to what sort(1) or strcoll(3) and other
>>>> string-comparing routines say?
>>> For example,
>>>
>>> $ expr č '<' d
>>> 0
>>>
>>> Which locale-specific collation sequence determined that?
>>> Byte by byte, it's
>>>
>>> c48d U+00010d č LATIN SMALL LETTER C HACEK
>>> 64 U+000064 d LATIN SMALL LETTER D
>>>
>>> and I don't think there is anything more to it.
Yes.
>>> (Although in the Czech alphabet, č comes just before d.)
Fair enough, but adding knowledge about that to the C library
would be quite insane.
> I don't know what Ingo et al plans wrt collation sequence are, but
> it is a relatively innocuous part of locales.
I think i said so several times: i talked to bapt@ when he implemented
LC_COLLATE support in the FreeBSD libc. To put it mildly, he disagreed
with your opinion. Or, to be clear, he was swearing because he hated
the resulting complexity, saying it was much worse than he had expected.
And i don't think bapt@ is easily scared.
> More specifically, the ISO committee introduced functions specifically
> to deal with collation sequence, and left the original raw C functions
> (strcmp and the like) completely pristine... so what's missing is mostly
> an engine to compile location tables into something fairly reasonable.
>
> There is way less of a security risk than, say, LC_CTYPE... ;)
I don't know. A fairly reliable way to create security risks is
complexity. Apart from the erratic run time behaviour that is likely to
trip up sysadmins - LC_COLLATE can change the collation sequence even
among ASCII characters - collation support looks like a very effective
way of putting excessive complexity right into the C library.
So, let me say it again, i would argue for rejecting it even if somebody
offered a complete patch implementing it. The C library is just the
wrong place for handling such matters.
Yours,
Ingo
