type_size_sort

static int type_size_sort(const struct object_entry *a, const struct
object_entry *b)
{
...
  return a < b ? -1 : (a > b);
}

This does not look valid. the standard says you must not depend on the location:

       [#4] When  the  same  objects  (consisting  of  size  bytes,
       irrespective  of  their  current positions in the array) are
       passed more  than  once  to  the  comparison  function,  the
       results  shall be consistent with one another.  That is, for
       qsort they shall define a total ordering on the  array,  and
       for  bsearch  the  same object shall always compare the same
       way with the key.

M.

Morten Welinder wrote:

It's perfectly correct. If the same list was to be passed to create_sorted_list() twice it will come out exactly the same the second time as it did the first. The only thing to remark on is that the return above could be written as below instead:

	return a - b;

Andreas Ericsson <ae@op5.se> writes:

And I suspect Morten would say the same thing about ptrdiff_t could be larger than an int.

I personally feel this would not make any practical difference on sane architectures either way, though..

That is not what the part of the standard I quoted says. It very clearly forbids the sorting function from depending on the pointers' values. I can even see an implementation actually using this requirement.

And it is well known that some qsort implementations will do nasty things if the sorting order is not consistent. I've seen Perl core dumps on that account, although that is a while ago.

M.

Morten Welinder <mwelinder@gmail.com> writes:

What you say is correct, and people should be careful when using qsort(), but it does not apply to this case. The patch I posted is not necessary. Andreas' rewrite quoted above, however, is invalid when ptrdiff_t (a-b) overflows int range.

The code as written by Linus back on June 25 is correct, but that sort callchain is written in an unusual way to confuse us (you were, and I was initially after seeing your message).

(1) The caller look like this.  It prepares an array of pointers
    in list[], calls qsort with sort_comparator() as the
    function to sort this list[].  Each element in this list[]
    is a pointer to struct object_entry.

	for (i = 0; i < nr_objects; i++)
		list[i] = objects + i;
	current_sort = sort;
	qsort(list, nr_objects, sizeof(struct object_entry *), sort_comparator);

(2) sort_comparator() is called by qsort() with the standard
    calling convention -- two pointers pointing into the array
    being sorted.  It calls current_sort() function set up by
    (1), giving it the pointers *FETCHED* *FROM* the locations
    these two incoming pointers are pointing at.

        static entry_sort_t current_sort;
        static int sort_comparator(const void *_a, const void *_b)
        {
                struct object_entry *a = *(struct object_entry **)_a;
                struct object_entry *b = *(struct object_entry **)_b;
                return current_sort(a,b);
        }

(3) Then type_size_sort() uses compariosn of these two pointers
    as the tiebreaker.

Notice? The comparison of two pointers you originally pointed out is not about the location in list[]. They are values stored there.

Ah, right you are.

Mildly relatedly, notice that a<b can be valid when a-b<0 is not. ptrdiff_t is not required to be big enough to hold the difference! (A highly dubious part of the C standard.)

M.

Morten Welinder <mwelinder@gmail.com> writes:

Then something like this?

---