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
Re: Refactoring base64 encoding and decoding into a safer interface |
Список | 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 по дате отправления: