Re: Upcoming GLib changes
- From: Tim Janik <timj gtk org>
- To: gtk-devel-list redhat com
- Subject: Re: Upcoming GLib changes
- Date: Wed, 30 Jun 1999 17:39:23 +0200 (CEST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]