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

[Aharon Robbins]

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