Re: Using the return value of strlcpy() and strlcat()

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Using the return value of strlcpy() and strlcat()
Дата
Msg-id CAKJS1f8FjLCD17EOKXcday9D4orxwhzkM22mzPVhm63jWkve-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Using the return value of strlcpy() and strlcat()  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Ответы Re: Using the return value of strlcpy() and strlcat()
Список pgsql-hackers
On Fri, 15 Mar 2019 at 00:11, Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > Mmm ... if there's a way to do it that's not messy and typo-prone,
> > maybe.  But I'm dubious that the potential gain is worth complicating
> > the code.  The strings involved aren't usually all that long.
>
> Please consider this patch withdrawn.

Amusingly it seems the strlcpy() return value of the chars it would
have copied if it didn't run out of space is not all that useful for
us. I see exactly 2 matches of git grep "= strlcpy".  The
isolation_init() one looks genuine, but the SerializeLibraryState()
looks a bit bogus. Looking at EstimateLibraryStateSpace() it seems it
estimates the exact space, so the strlcpy should never cut short, but
it does seem like a bad example to leave laying around.

We should have maybe thought a bit harder when we put that strlcpy
code into the codebase and considered if we might have been better off
inventing our own function that just returns what it did copy instead
of what it would have.

--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Removing unneeded self joins
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] PATCH: multivariate histograms and MCV lists