[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Darrington
Subject: PSPP-BUG: Re: [bug #12931] ONEWAY transposes output rows/columns
Date: Mon, 2 May 2005 15:36:40 +0800
User-agent: Mutt/1.3.28i

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


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.

Attachment: pgpXILkzpw4Ih.pgp
Description: PGP signature

reply via email to

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