Re: pstrndup()

Поиск
Список
Период
Сортировка
Искать
От
Karel Zak
Тема
Re: pstrndup()
Дата
Msg-id
20040322070528.GB9385@zf.jcu.cz
Ответ на
Re: pstrndup() (Tom Lane)
Список
Дерево обсуждения
pstrndup() Karel Zak <zakkr@zf.jcu.cz>
Re: pstrndup() Bruce Momjian <pgman@candle.pha.pa.us>
Re: pstrndup() Tom Lane <tgl@sss.pgh.pa.us>
Re: pstrndup() Karel Zak <zakkr@zf.jcu.cz>
Re: pstrndup() Bruce Momjian <pgman@candle.pha.pa.us>
Re: pstrndup() Tom Lane <tgl@sss.pgh.pa.us>
Re: pstrndup() Karel Zak <zakkr@zf.jcu.cz>
Re: pstrndup() Bruce Momjian <pgman@candle.pha.pa.us>
On Sun, Mar 21, 2004 at 11:45:18PM -0500, Tom Lane wrote:
> Bruce Momjian  writes:
> > Karel, do you plan to use pstrndup for some purpose?  I assume so.

 I   think    PostgreSQL   should   supports   basic    operation   with
 allocation/strings if  it's open for  users' C functions and  we expect
 our own memory system usage.

> I am not familiar with strndup.  If the spec is like strncpy, I would
> vote against including it ... strncpy is so broken that we had to invent
> our own variant ...

 POSIX strncpy()  is different,  a result from  strncpy needn't  be zero
 terminated. You're right it's horrible function.
 
 The result of  strndup() is always zero terminated. It's  more safe and
 strndup() is  binary safe because  it doesn't check something  in input
 string. The pstrndup() is based on PostgreSQL memory managment.

    Karel

-- 
 Karel Zak  
 http://home.zf.jcu.cz/~zakkr/
В списке pgsql-patches по дате отправления
От: Manfred Spraul
Дата:
От: Andrew Dunstan
Дата:
FAQ