[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: |
Peter Fales |
Subject: |
Re: [bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20 |
Date: |
Mon, 25 Jul 2011 12:05:38 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Aharon,
I haven't actually tested this, but that doesn't look right to
me. You have it returning a boolean (v1 < v2) in the string case
and and positive/zero/negative in the numeric case. Shouldn't it
have logic like comp_val_str?
On Fri, Jul 22, 2011 at 11:43:07AM +0300, Aharon Robbins wrote:
> 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
--
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