[PATCH 14/15] xkb: Use memcpy for copy
Peter Hutterer
peter.hutterer at who-t.net
Wed Jul 28 16:21:02 PDT 2010
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
More information about the xorg-devel
mailing list