bug-gawk
[Top][All Lists]
Advanced

[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: Thu, 28 Jul 2011 21:39:25 +0300
User-agent: Heirloom mailx 12.4 7/29/08

Hi. Re this:

> 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.

It's basically a bug in the test, since it doesn't do a comparison that
leads to a stable sort, which is what the test suite needs to work.

Here is a patch that will get pushed out shortly.

Thanks,

Arnold
------------------------------------------------------------
diff --git a/test/ChangeLog b/test/ChangeLog
index e4ad2f3..e3af32a 100644
--- a/test/ChangeLog
+++ b/test/ChangeLog
@@ -1,3 +1,8 @@
+2011-07-28         Arnold D. Robbins     <address@hidden>
+
+       * sortu.awk, sortu.ok: Modified to make numeric comparison do
+       a stable sort.
+
 2011-07-26         Arnold D. Robbins     <address@hidden>
 
        * Makefile.am (getline4, gsubtst8): New tests.
diff --git a/test/sortu.awk b/test/sortu.awk
index b4d3013..508dc07 100644
--- a/test/sortu.awk
+++ b/test/sortu.awk
@@ -16,8 +16,12 @@ function comp_idx_num(s1, v1, s2, v2)
 }
 
 # ascending value number
-function comp_val_num(s1, v1, s2, v2)
+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 comp_val_str(s1, v1, s2, v2)
        return (v1 - v2)
 }
 
diff --git a/test/sortu.ok b/test/sortu.ok
index ba9ac99..06dcd94 100644
--- a/test/sortu.ok
+++ b/test/sortu.ok
@@ -13,9 +13,9 @@ rat       tar
 100       5
 4         1
 --- asort(a, b, "comp_val_num"), IGNORECASE = 0---
-[1]       :barz      barz      
-[2]       :blattt    blattt    
-[3]       :Zebra     Zebra     
+[1]       :barz      Zebra     
+[2]       :blattt    barz      
+[3]       :Zebra     blattt    
 [4]       :1234      234       
 [5]       :234       1234      
 --- asort(a, b, "comp_val_str"), IGNORECASE = 0---



reply via email to

[Prev in Thread] Current Thread [Next in Thread]