|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Refactoring base64 encoding and decoding into a safer interface|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 2 Jul 2019, at 07:41, Michael Paquier <michael(at)paquier(dot)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:
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.
|Next Message||Masahiko Sawada||2019-07-02 07:58:56||Re: [PATCH] Speedup truncates of relation forks|
|Previous Message||Michael Paquier||2019-07-02 07:49:12||Re: Replacing the EDH SKIP primes|