[bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20

[Peter Fales]

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