Skip site navigation (1) Skip section navigation (2)

Re: Faster StrNCpy

From: mark(at)mark(dot)mielke(dot)cc
To: Markus Schaber <schabi(at)logix-tt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Faster StrNCpy
Date: 2006-09-29 20:42:39
Message-ID: 20060929204239.GA30048@mark.mielke.cc (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Fri, Sep 29, 2006 at 11:21:21AM +0200, Markus Schaber wrote:
> Tom Lane wrote:
> >> Just wondering - are any of these cases where a memcpy() would work
> >> just as well? Or are you not sure that the source string is at least
> >> 64 bytes in length?
> > 
> > In most cases, we're pretty sure that it's *not* --- it'll just be a
> > palloc'd C string.
> > 
> > I'm disinclined to fool with the restriction that namestrcpy zero-pad
> > Name values, because they might end up on disk, and allowing random
> > memory contents to get written out is ungood from a security point of
> > view.
> 
> There's another disadvantage of always copying 64 bytes:
> 
> It may be that the 64-byte range crosses a page boundary. Now guess what
> happens when this next page is not mapped -> segfault.

With strncpy(), this possibility already exists. If it is a real problem,
that stand-alone 64-byte allocations are crossing page boundaries, the
fault is with the memory allocator, not with the user of the memory.

For strlcpy(), my suggestion that Tom quotes was that modern processes
do best when instructions can be fully parallelized. It is a lot
easier to parallelize a 64-byte copy, than a tight loop looking for
'\0' or n >= 64. 64 bytes easily fits into cache memory, and modern
processors write cache memory in blocks of 16, 32, or 64 bytes anyways,
meaning that any savings in terms of not writing are minimal.

But it's only safe if you know that the source string allocation is
>= 64 bytes. Often you don't, therefore it isn't safe, and the suggestion
is unworkable.

Cheers,
mark

-- 
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


In response to

Responses

pgsql-hackers by date

Next:From: markDate: 2006-09-29 21:23:31
Subject: Re: Faster StrNCpy
Previous:From: David FetterDate: 2006-09-29 20:14:46
Subject: Re: Per-database search_path

pgsql-patches by date

Next:From: markDate: 2006-09-29 21:23:31
Subject: Re: Faster StrNCpy
Previous:From: Tom LaneDate: 2006-09-29 14:59:22
Subject: Re: Faster StrNCpy

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group