On Tue, Feb 6, 2024, at 4:30 PM, Paul Eggert wrote:
> On 2/6/24 07:00, Zack Weinberg wrote:
>> This sentence only makes sense to me because of what you said in the
>> cover letter, about the array not being required to be totally
>> ordered.
> the paraphrase you sent was too generous, as it allowed the 
> array to be in completely random order if it had no matching element
> ... we're likely better off sticking with POSIXish wording.

I see what was wrong with the way I wrote it, but I really don't like
the "POSIXish wording".  To me it trips over the English-language ambiguity
of whether the "all" in "all X, Y, and Z" is meant to apply to Y and Z as
well as X. I revised my suggestion again (see attached patch).

>> and C2011 7.22.5p2 actually makes this a hard requirement: “The
>> implementation shall ensure that both arguments [of the comparison
>> function called by qsort] are pointers to elements of the array.”
>> It looks to me like there are situations where our implementation
>> doesn’t do this:
>
> I don't see that in the glibc source. Are you sure about that?

I was wrong about this; I misread the code in qsort.c.  Specifically,
I missed that msort_with_tmp always merges *from* two subsets of the
main array, *into* the temporary array, and then copies the result back
to the main array.  Still, I think it is likely that some C libraries in
the past have failed to implement this requirement (intentionally or not).
In the attached patch I revised that suggestion again and I hope it satisfies
everyone's expectations now.

I might send another patch for this file later; I think it would be clearer to
consolidate most of the new language about how the comparison function is required
to behave into the "Comparison Functions" node.

zw