Re: [PATCH 9/9] mergesort: use ranks stack

["René Scharfe" <l.s.r@web.de>]

Am 18.01.22 um 11:40 schrieb Ævar Arnfjörð Bjarmason:
>
> On Tue, Jan 18 2022, René Scharfe wrote:
>
>> Am 17.01.22 um 19:22 schrieb René Scharfe:
>>> Am 17.01.22 um 18:43 schrieb Ævar Arnfjörð Bjarmason:
>>>>
>>>> On Fri, Oct 01 2021, René Scharfe wrote:
>>>>
>>>>
>>>>> +/*
>>>>> + * Perform an iterative mergesort using an array of sublists.
>>>>> + *
>>>>> + * n is the number of items.
>>>>> + * ranks[i] is undefined if n & 2^i == 0, and assumed empty.
>>>>> + * ranks[i] contains a sublist of length 2^i otherwise.
>>>>> + *
>>>>> + * The number of bits in a void pointer limits the number of objects
>>>>> + * that can be created, and thus the number of array elements necessary
>>>>> + * to be able to sort any valid list.
>>>>> + *
>>>>> + * Adding an item to this array is like incrementing a binary number;
>>>>> + * positional values for set bits correspond to sublist lengths.
>>>>> + */
>>>>>  void *llist_mergesort(void *list,
>>>>>  		      void *(*get_next_fn)(const void *),
>>>>>  		      void (*set_next_fn)(void *, void *),
>>>>>  		      int (*compare_fn)(const void *, const void *))
>>>>>  {
>>>>> -	unsigned long l;
>>>>> -
>>>>> -	if (!list)
>>>>> -		return NULL;
>>>>> -	for (l = 1; ; l *= 2) {
>>>>> -		void *curr;
>>>>> -		struct mergesort_sublist p, q;
>>>>> +	void *ranks[bitsizeof(void *)];
>>>>> +	size_t n = 0;
>>>>> +	int i;
>>>>>
>>>>> -		p.ptr = list;
>>>>> -		q.ptr = get_nth_next(p.ptr, l, get_next_fn);
>>>>> -		if (!q.ptr)
>>>>> -			break;
>>>>> -		p.len = q.len = l;
>>>>> +	while (list) {
>>>>> +		void *next = get_next_fn(list);
>>>>> +		if (next)
>>>>> +			set_next_fn(list, NULL);
>>>>> +		for (i = 0; n & (1 << i); i++)
>>>>> +			list = llist_merge(ranks[i], list, get_next_fn,
>>>>> +					   set_next_fn, compare_fn);
>>>>> +		n++;
>>>>> +		ranks[i] = list;
>>>>> +		list = next;
>>>>> +	}
>>>>
>>>> (Commenting on a commit integrated into v2.34.0)
>>>>
>>>> The aCC compiler on HP/UX notes:
>>>>
>>>>     "mergesort.c", line 67: warning #2549-D: variable "ranks" is used before its value is set
>>>>                         list = llist_merge(ranks[i], list, get_next_fn,
>>>>
>>>> It's commenting on the ranks[i] within the for-loop-within-while-loop
>>>> above.
>>>
>>> That would be a bug.  I think none of the array elements are read before
>>> they are written -- but of course I'm biased.  Can that compiler show a
>>> sequence that would lead to reading uninitialized data?  Or anyone else?
>>>
>>> Initializing the array would memset(3) 128 bytes on 32-bit systems and
>>> 512 bytes on 64-bit systems.  Doing that everywhere just to appease a
>>> confused compiler on a dying platform would be merciful, but still sad.
>>
>> Does the warning disappear if you add "ranks[0] = NULL;" before the while
>> loop?  And if it does, has adding "if (n & 1) ranks[0] = NULL;" instead
>> the same effect?
>
> Both of those make the warning go away.

The second one is optimized out by GCC and Clang because n == 0 before
the while loop.  The data flow analysis in aCC that leads to the warning
must be taking some shortcuts if can be fooled by an inconsequential
expression.

> Anyway, if you think the pre-image in master now is fine let's leave it
> as it is. There's no point in just trying to appease aCC here.
>
> I just thought I'd send a quick mail about it because I was looking at
> its warning output, most of those warnings point to obviously harmless
> issues, but I thought this one *might* point to an actual logic error
> (but didn't look carefully enough myself), so I thought I'd send a quick
> note about it.

Sure, it would be a disaster if this loop somehow read uninitialized
data, and any hint needs towards that end must be taken seriously.  But
that warning from aCC seems to be a false positive.

Adding "if (n & 1) ranks[0] = NULL;" before the loop and a comment would
not change the code generated by  "normal" optimizing compilers, so we
could add this at the cost of slightly hurting readability, if necessary.

> If you think not it's probably best just to leave the code as-is.

That works for me as well. :)

René