Re: Upcoming GLib changes

[Tim Janik <timj gtk org>]

On 30 Jun 1999, Soeren Sandmann wrote:

> 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
> sorry.
> 
> --- configure.in.orig   Wed Jun 30 16:43:06 1999
> +++ configure.in        Wed Jun 30 16:50:34 1999
> @@ -1332,10 +1332,13 @@
>    ;;
>  *)
>    glib_memmove="
> -/* 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"
>    ;;
>  esac

if g_memmove() is used with very big memory portions, you can't neccessarily
rely on being able to allocate that amount on the fly. the best solution would
be a configure check which figures whether bcopy() handles overlapping memory
areas or not, and if that is not the case, simply roll our own for() loop for
s < d < s + n (eventhough d < s < d + n overlaps as well, i've not yet heard of
a copying mechanism that couldn't handle that).

> 
> 
> Søren Sandmann
> 
> 

---
ciaoTJ