Re: Upcoming GLib changes

Tim Janik <> writes:

> 2) the current random number implementation provides two sets of interfaces.
>    one uses a context structure (containing some state information to produce
>    the next random number) to allow multiple streams of repeatable random
>    numbers, and works well in a threaded environment with no lock overhead.
>    The other one is built on top of this and uses a single global context
>    for a simplified interface. This simplified interface works
>    like the old-fashioned unix rand() and srand() functions, using a global
>    lock for thread safety.
>    there was disagreement over whether the second interface was necessary.
>    i liked it, but Owen and Federico thought it was confusing and unecessary
>    bloat.

In my opinion there is no need for the second interface. It is more in
the spirit of GLib to use a context structure. Also, it doesn't seems
clean to have two interfaces to the same thing.

There is another issue with GLib. If memmove is not present, glib.h
implements g_memmove with bcopy, which is not guaranteed to handle
overlapping memory areas correct. This is bad since garray.c depends
on g_memmove handling overlapping areas correct.

I would suggest the following patch. It is better to be safe than

---   Wed Jun 30 16:43:06 1999
+++        Wed Jun 30 16:50:34 1999
@@ -1332,10 +1332,13 @@
-/* We make the assumption that if memmove isn't available, then
- * bcopy will do the job. This isn't safe everywhere. (bcopy can't
- * necessarily handle overlapping copies) */
-#define g_memmove(d,s,n) G_STMT_START { bcopy ((s), (d), (n)); } G_STMT_END"
+/* If memmove isn't available, then we do the job with bcopy */
+#define g_memmove(d,s,n) G_STMT_START { gpointer tmp; \
+                                        tmp = g_malloc(n); \
+                                        bcopy ((tmp), (s), (n)); \
+                                        bcopy ((d), (tmp), (n)); \
+                                        g_free (tmp); \
+                                      } G_STMT_END"

Søren Sandmann

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