Re: [gtk-list] Re: Are GHashTable's deterministic?

["Stéphane Popinet" <popinet lmm jussieu fr>]

Eivind Kvedalen wrote:

> Has your foreach handler any side-effects, i.e does it change some global
> variable ?

I have reproduced the behavior with a very simple piece of code.
You can have a look at the source code below.

> Hashes are not sorted, and you cannot depend on your handler
> being called in any specific order. If the handler changes some global
> variable, unpredictable results can occur.

I am certainly not requiring that the hash table be traversed in any
specific order but I would like it to be traversed in the same order for
two different runs of the "same" code: i.e. two versions of the same
code, one of which only differ by some added code NOT CALLED but
occupying some space in the process memory. My guess is that the memory
occupied by the code modifies the way the hash table is generated and
thus the order of traversal. I would like to know if this guess is
correct or not.

I wrote the little code below which examplify this behavior.
the function surface_read just fills in hash table s->triangles from a
file. id (t) just returns a unique number corresponding to the order of
creation of the triangle t. In that case, the output of the program
(i.e. the order in which the hash table is traversed) is the same when
the same code is run multiple times but differs if the code is linked to
an object surface.o which size is different (the function surface_read
NOT being modified in any way).

#include "surface.h"

void triangle_bbox_list (triangle_t * t, 
			 gpointer t_data,
			 gpointer user_data)
{
  fprintf (stderr, "%d\n", id (t));
}

int main (int argc, char * argv[])
{
  surface_t * s;
  FILE * fptr = fopen (argv[1], "rt");

  s = surface_read (fptr);
  fclose (fptr);
  
  g_return_val_if_fail (s != NULL, 1);

  surface_foreach_triangle (s, (GHFunc)triangle_bbox_list, NULL);
  g_hash_table_foreach (s->triangles, triangle_bbox_list, NULL);
}