This is the mail archive of the mailing list for the glibc 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: [RFC] strcpy optimizations

On Tue, Jan 29, 2013 at 01:30:09PM -0800, Paul Eggert wrote:
> On 01/29/13 12:15, OndÅej BÃlka wrote:
> > I need to know if it is safe for example to use pblendvb 
> > on high 8 bytes while other thread modifies lower 8 bytes?
> Why wouldn't it be safe?  If two threads strcpy into the same
> buffer, or one strcpies from a buffer while another is
> strcpying into that buffer, the resulting behavior is undefined,
> so the GNU C library can do what it likes.  It shouldn't
> matter whether pblendvb is atomic; you should be able to use it.
I wanted to use it only to bytes which change. 
There is problem with code like this:
struct foo {
  long x;
  char y[8];
  long z;
foo f;

With f.x++;              in first thread
With f.z++;              in second thread
and  strcpy (f.y, "abc") in third thread.
> > Third question is what usage is worth optimizing. When I looked how 
> > firefox(biggest usage on my computer) most of calls are used to copy 
> > a english dictonary. I do not know what is used strncpy in font 
> > configuration which also takes considerable portion
> strncpy should be lower priority, I'd say.  Typically, a program
> that uses strncpy doesn't care all that much about performance.

I will consider strcpy and strncpy separately. But I was also interested
why it used strncpy to copy string one byte a time.

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