Re: T610 failing on Fedora rawhide

Subject: Re: T610 failing on Fedora rawhide

Date: Fri, 24 Nov 2023 16:04:49 +0100

To: David Bremner

Cc: Michael J Gruber, notmuch@notmuchmail.org

From: Florian Weimer


* David Bremner:

> Michael J Gruber <michaeljgruber+grubix+git@gmail.com> writes:
>
>> during my first tests for Python 3.13 (hooray...) I noticed that some tests
>> in T610 started to fail independent of that. It seems that with notmuch
>> 0.38.1 on current Fedora rawhide,  `notmuch_message_get_properties()`
>> returns properties in a different order, while the tests expect a specific
>> order. So I'm wondering:
>> - Is there a particular order which the interface promises to deliver?
>> - If yes: What could cause it to be different?
>> If not there's some work to do making the tests independent of the order ...
>> This is not glib again, is it?
>
> The order is the result of sorting the keys (property names) using the
> system qsort. So the first is potentially explicable, but the second
> suggests a strange (to me) collation order. Do you happen to know the
> locale used by these runs?
>
> Ultimately the comparisons are done with strcmp (string-map.c).

strcmp doesn't follow the locale.

The qsort in glibc was never a stable sort, but it looked like that in
many cases.  The version currently in Fedora rawhide (from the upcoming
glibc upstream version) shows non-stable sorting behavior in more cases.
The test case uses identical sort keys (testkey1, testkey 3), which is
why its output changes.

Still this is useful feedback.  Maybe our qsort was a mostly stable sort
for so long that it's now part of the interface contract.

Thanks,
Florian

_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Thread: