PSPP-BUG: Re: [bug #12931] ONEWAY transposes output rows/columns

[John Darrington]

On Mon, May 02, 2005 at 06:28:03AM +0000, Ben Pfaff wrote:

     The ONEWAY procedure assumes that hash tables happen to iterate in an
     expected order.  If they don't, then output rows or columns are
     transposed.  
     I changed the hash table implementation and now the tests fail.
     I am pretty sure that the hash table is correct and that the
     ONEWAY code needs fixing. 
                 
     This comment in ONEWAY makes me assume it's a ONEWAY bug:
                                   
       /* FIXME: Potential danger here.
       We're ASSUMING THE array is in the order corresponding to the 
       hash order. */
                                                             
     Perhaps you could use hsh_sort() or hsh_sort_copy() to help with
     the solution. 

You're right.  I added a quick hsh_sort in the relevant places and it
seems to fix the problem, but I have some concerns about this:

From hash.c:
/* Sorts hash table H based on hash comparison function.
   ....  After calling this function, only hsh_destroy()
   and hsh_count() may be applied to H. */

This implies that it's not safe to iterate a hash after sorting it.  
Is it safe to do so?  And after sorting, will it iterate in the sorted
order?  

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

pgpXILkzpw4Ih.pgp
Description: PGP signature