Re: [PATCH] Fix buffer not null terminated on (ecpg lib)
Вложения
В списке pgsql-hackers по дате отправления:
| От | Ranier Vilela |
|---|---|
| Тема | Re: [PATCH] Fix buffer not null terminated on (ecpg lib) |
| Дата | |
| Msg-id | CAEudQApqcJpAsbhsHM6FOwVxUsKNV=X8WxBpr10ipB-acEpwWw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Fix buffer not null terminated on (ecpg lib) (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
Hi,
On 2021-06-15 13:53:08 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2021-06-15 07:40:46 -0300, Ranier Vilela wrote:
> >> memcpy would not suffer from it?
>
> > It'd not be correct for short sqlstates - you'd read beyond the end of
> > the source buffer. There are cases of it in the ecpg code.
>
> What's a "short SQLSTATE"? They're all five characters by definition.
I thought there were places that just dealt with "00" etc. And there are - but
it's just comparisons.
I still don't fully feel comfortable just using memcpy() though, given that
the sqlstates originate remotely / from libpq, making it hard to rely on the
fact that the buffer "ought to" always be at least 5 bytes long? As far as I
can tell there's no enforcement of PQresultErrorField(..., PG_DIAG_SQLSTATE)
being that long.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера