Re: Refactoring base64 encoding and decoding into a safer interface

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Refactoring base64 encoding and decoding into a safer interface
Дата
Msg-id 42D26652-6DBF-4705-BEA4-7D107F8B687C@yesql.se
обсуждение исходный текст
Ответ на Re: Refactoring base64 encoding and decoding into a safer interface  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Refactoring base64 encoding and decoding into a safer interface  (Michael Paquier <michael@paquier.xyz>)
Re: Refactoring base64 encoding and decoding into a safer interface  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
> On 2 Jul 2019, at 07:41, Michael Paquier <michael@paquier.xyz> wrote:

>> In the below passage, we leave the input buffer with a non-complete
>> encoded string.  Should we memset the buffer to zero to avoid the
>> risk that code which fails to check the return value believes it has
>> an encoded string?
>
> Hmm.  Good point.  I have not thought of that, and your suggestion
> makes sense.
>
> Another question is if we'd want to actually use explicit_bzero()
> here, but that could be a discussion on this other thread, except if
> the patch discussed there is merged first:
> https://www.postgresql.org/message-id/42d26bde-5d5b-c90d-87ae-6cab875f73be@2ndquadrant.com

I’m not sure we need to go to that length, but I don’t have overly strong
opinions.  I think of this more like a case of “we’ve changed the API with new
errorcases that we didn’t handle before, so we’re being a little defensive to
help you avoid subtle bugs”.

> Attached is an updated patch.

Looks good, passes tests, provides value to the code.  Bumping this to ready
for committer as I no more comments to add.

cheers ./daniel


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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Replacing the EDH SKIP primes
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PATCH] Speedup truncates of relation forks