Re: Error in calculating length of encoded base64 string - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Error in calculating length of encoded base64 string
Date
Msg-id 20230826174331.kfvsktyorljxw3qx@alvherre.pgsql
Whole thread Raw
In response to Re: Error in calculating length of encoded base64 string  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2023-Jun-09, Tom Lane wrote:

> Gurjeet Singh <gurjeet@singh.im> writes:
> > On Thu, Jun 8, 2023 at 7:35 AM Tom Lane <tgl@sss.pgh.pa.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/



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] Add XMLText function (SQL/XML X038)
Next
From: Chapman Flack
Date:
Subject: Re: [PATCH] Add XMLText function (SQL/XML X038)