bug-gzip
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: gzip use of memcpy


From: Alain Magloire
Subject: RE: gzip use of memcpy
Date: Fri, 8 Jan 2010 13:14:49 -0500

> From: Jim Meyering [mailto:address@hidden
> Sent: Friday, January 08, 2010 12:56 PM
> To: Alain Magloire
> Cc: address@hidden
> Subject: Re: gzip use of memcpy
> 
> Alain Magloire wrote:
> > Bonjour,
> 
> Bonjour Alain !  Bonne anneƩ !
> It's been too long ;-)
>

8-)
Yes, I agree. My best wishes to you also.

> > The behavior of memcpy is well defined:
> >
> > "Copying overlapping buffers isn't guaranteed to work; use memmove() to
> > copy buffers that overlap"
> >
> > In our case for the SH architecture we have a version of memcpy that
> > takes advantage at some specific instruction and above a certain size
> > the copy will be done in reverse (side effect of the optimization).
> >
> > For overlapping copies, the code should be using memmove() as describe
> > in POSIX.
> ...
> > Index: inflate.c
> ...
> >          if (w - d >= e)
> >          {
> > -          memcpy(slide + w, slide + d, e);
> > +          memmove(slide + w, slide + d, e);
> 
> Can you give sample values of w, d and e for which this change
> makes a difference?  Doesn't the preceding (w - d >= e) guard
> ensure that the source and destination buffers never overlap?
>

Correct, I will try to get you the test case.  It was from a bad gzip/tar, let 
me see if I can get the tester on my team to give me the values, hold on...

> > Index: deflate.c
> ...
> > -        memcpy((char*)window, (char*)window+WSIZE, (unsigned)WSIZE);
> > +        memmove((char*)window, (char*)window+WSIZE, (unsigned)WSIZE);
> 
> The source and destination buffers do not overlap.

You are correct. I have changed it without thinking.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]