Re: Error in calculating length of encoded base64 string

On 2023-Jun-09, Tom Lane wrote:

> Gurjeet Singh <gurjeet(at)singh(dot)im> writes:
> > On Thu, Jun 8, 2023 at 7:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> This bug is very ancient, dating to commit 79d78bb26 which
> >> added encode.c. (The other instances were presumably copied
> >> from there.) Still, it doesn't quite seem worth back-patching.
>
> > Is it worth investing time in trying to unify these 3 occurrences of
> > base64 length (and possibly other relevant) code to one place? If yes,
> > I can volunteer for it.
>
> I wondered about that too. It seems really silly that we made
> a copy in src/common and did not replace the others with calls
> to that.

I looked into this. It turns out that there is a difference in newline
handling in the other routines compared to what was added for SCRAM,
which doesn't have any (and complains if you supply them). Peter E
did suggest to unify them at the time:
https://www.postgresql.org/message-id/947b9aff-8fdb-dbf5-a99c-0ffd4523a73f%402ndquadrant.com

We could add a boolean "whitespace" flag to both of
src/common/base64.c's pg_b64_encode() and pg_b64_decode(); with that I
think it could serve the three places that need it.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/