This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:
>>
>>     PTR
>>     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
>> and
>> 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.  :-)

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]