[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20
From: |
Aharon Robbins |
Subject: |
Re: [bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20 |
Date: |
Fri, 22 Jul 2011 11:43:07 +0300 |
User-agent: |
Heirloom mailx 12.4 7/29/08 |
Hi. Apologies for not answering earlier, this got buried in my inbox.
I think you are right; we are expecting qsort() to be stable - the built-in
comparison functions go to extra work to make the results be stable.
The test should probably be enhanced to something like:
function comp_val_num(s1, v1, s2, v2, num)
{
num = "^[-+]?([0-9]+[.]?[0-9]*|[.][0-9]+)([eE][-+]?[0-9]+)?$"
# force stable sort, compare as strings if not numeric
if ((v1 - v2) == 0 && (v1 !~ num || v2 !~ num))
return v1 < v2
return (v1 - v2)
}
Thanks,
Arnold
> Date: Fri, 1 Jul 2011 10:10:21 -0500
> From: Peter Fales <address@hidden>
> To: address@hidden
> Subject: [bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20
>
> I'm not completely sure that this is a bug. However, the README
> file in the test directory says that any mismatches between
> _foo and foo.ok should be reported as a bug.
>
> On our HP/UX 10.20 machine, the sortu test is failing. The actual
> results are:
>
> --- asort(a, b, "comp_val_num"), IGNORECASE = 0---
> [1] :barz Zebra
> [2] :blattt blattt
> [3] :Zebra barz
> [4] :1234 234
> [5] :234 1234
>
> but the expected results in sortu.ok are:
>
> --- asort(a, b, "comp_val_num"), IGNORECASE = 0---
> [1] :barz barz
> [2] :blattt blattt
> [3] :Zebra Zebra
> [4] :1234 234
> [5] :234 1234
>
> The numeric values are correctly sorted in numeric order, and string
> values (numerically zero) are correctly placed at the beginning.
> Apparently, the test expects the sort to be stable, but I can't find
> any indication of that in the documentation.
>
> So, I'm not sure if this is a bug in the test (the change in the
> order of the first three values is OK), the documentation (which
> should say that the sort is stable), or the code (which does not
> implement a stable sort).
>
> It looks like array.c depends on the system-supplied qsort(). Is that
> the issue? The HP/UX man page for qsort says:
>
> The order in the output of two items which compare as equal is
> unpredictable.
>
> But, the linux (Fedora 14) man page has similar language:
>
> If two members compare as equal, their order in the sorted array is
> undefined.
> --
> Peter Fales
> Alcatel-Lucent
> Member of Technical Staff
> 1960 Lucent Lane
> Room: 9H-505
> Naperville, IL 60566-7033
> Email: address@hidden
> Phone: 630 979 8031