Re: [gtk-list] Re: newcomer question: compiling gtk - memmove...

[Owen Taylor <owt1 cornell edu>]

> Marcus> Any ideas as to what I might be doing wrong? Or workarounds?
> 
> You aren't doing anything wrong.
> 
> A workaround would be to get a replacement memmove and put it into gtk
> when the OS doesn't provide one.  This is quite simple to do.  I'd do
> it, but I'm not sure about the official GTk position on replacement
> functions.  Would it be better to write `g_memmove' and change all the
> calls in GTk?  (That is what is done for strdup, for instance.  Is
> this really necessary?)

Currently in CVS is:

/* 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) */
#ifdef HAVE_MEMMOVE
#define g_memmove memmove
#else 
#define g_memmove(a,b,c) bcopy(b,a,c)
#endif

With HAVE_MEMMOVE defined by a configure check. I used the g_memmove
name mostly to be consistent with g_strdup, etc. - but thinking
about some more g_strdup is really a bit different, since it
has different semantics than strdup() (It dies on out-of-memory,
instead of returning NULL)

Providing a memmove replacement is probably better than using bcopy
(the native bcopy may be faster, but less sure). If it had exactly
the semantics of memmove, there probably is no problem with calling
it memmove().

(Au contraire, if another library also provides a subsititute for
memmove(), then perhaps there could be linker problems?) 

Regards,
                                        Owen