[PATCH 14/15] xkb: Use memcpy for copy

[Peter Hutterer]

On Wed, Jul 28, 2010 at 02:11:05PM +0300, Pauli Nieminen wrote:
> On 28/07/10 11:48 +0200, ext Mark Kettenis wrote:
> > > Date: Wed, 28 Jul 2010 09:25:10 +1000
> > > From: Peter Hutterer <peter.hutterer at who-t.net>
> > > 
> > > On Tue, Jul 27, 2010 at 03:09:55PM +0300, Pauli Nieminen wrote:
> > > > Source and destination have well defined size so use memcpy instead of
> > > > strncpy. strncpy tryes to add NULL to end of destination but it is not
> > >                    ^ "tries"
> > > > possible if source doesn't have NULL.
> 
> > > 
> > > my strncpy man page claims that if there is "no null byte among the first n
> > > bytes of src, the string placed in dest will not be null terminated." That's
> > > counter to what the message above says.
> 
> static analyzer complains about possible missing NULL termination for string,

meh. fix the analyzer, this is known behaviour of strncpy().
 
> Also code is already mainly using memcpy for same copy in other places. That
> why I tough change to memcpy would make sense. I should have added that to
> commit message.

yep, because then I wouldn't have complained about the patch :)

> > That's correct.  It's why strlcpy(3) was invented in the non-Linux
> > world; strlcpy(3) guarantees that the copied string is
> > null-terminated.
> > 
> > So I agree with Peter that this change doesn't make a lot of sense.
> > Potentially strncpy(3) will be faster than memcpy(3) since it will
> > stop copying after a null character.
> 
> memcpy will be faster unless you can skip a lot of memory areal. Checking for
> each byte for NULL is a lot more expensive than just doing copy unconditionaly. 

I don't think the speed difference between strncpy and memcpy will be of
much significance in the XKB geometry code. :)

Cheers,
  Peter