Re: Faster StrNCpy

Поиск
Список
Период
Сортировка
От Markus Schaber
Тема Re: Faster StrNCpy
Дата
Msg-id 451CE591.9030108@logix-tt.com
обсуждение исходный текст
Ответ на Re: Faster StrNCpy  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Faster StrNCpy  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Faster StrNCpy  (mark@mark.mielke.cc)
Список pgsql-hackers
Hi, Tom,

Tom Lane wrote:
> "Strong, David" <david.strong@unisys.com> writes:
>> 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.

Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Another idea for dealing with cmin/cmax
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Block B-Tree concept