This is the mail archive of the
mailing list for the GCC project.
Re: Obvious fix for libiberty/md5.c
Nick Clifton wrote:
> Hi Kaveh,
>>> I hope that the following patch counts as obvious: The
>>> md5_process_bytes() routine in libiberty/md5.c uses the return value
>>> of the memcpy() function, but under certain circumstances memcpy can
>>> be aliased to bcopy() and bcopy does not have a return value.
>> The "alias" of memcpy in libiberty itself handles the return type:
>> memcpy (PTR out, const PTR in, size_t length)
>> bcopy(in, out, length);
>> return out;
>> On what platform do we run into a situation where we're missing memcpy
>> this doesn't work? Is there some system header that defines bcopy ->
>> memcpy directly?
> Actually I was referring to the #define near the start of md5.c:
> # ifndef HAVE_MEMCPY
> # define memcpy(d, s, n) bcopy ((s), (d), (n))
> # endif
> Which I was triggering due to a configuration error in a toolchain I was
> building. Whilst it was simple enough to fix the configuration problem,
> the compiler error I received from using bcopy as an alias of memcpy
> bugged me enough to make me create this patch.
That sounds good. However, I can't help wondering whether the right thing
might be to delete that #define. Under what possible circumstances do we
expect md5 to run on a box with no memcpy but with bcopy()? But this is
pointless quibbling, I accept. :-)