Re: Replace remaining StrNCpy() by strlcpy()

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Replace remaining StrNCpy() by strlcpy()
Дата
Msg-id e7da7abc-3b55-3979-726c-72f91a3af0ce@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Replace remaining StrNCpy() by strlcpy()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Replace remaining StrNCpy() by strlcpy()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2020-08-03 19:39, Tom Lane wrote:
>> That's easy to fix, but it's perhaps wondering briefly why it needs to
>> be zero-padded.  hashname() doesn't care, heap_form_tuple() doesn't
>> care.  Does anything care?
> 
> We do have an expectation that there are no undefined bytes in values to
> be stored on-disk.  There's even some code in coerce_type() that will
> complain about this:

Okay, here is a new patch with improved implementations of namecpy() and 
namestrcpy().  I didn't see any other places that relied on the 
zero-filling behavior of strncpy().

>> While we're here, shouldn't namestrcpy() do some pg_mbcliplen() stuff
>> like namein()?
> 
> Excellent point --- probably so, unless the callers are all truncating
> in advance, which I doubt.

I will look into that separately.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Вложения

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Reduce/eliminate the impact of FPW
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch