Re: Fix misuse use of pg_b64_encode function (contrib/postgres_fdw/connection.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Fix misuse use of pg_b64_encode function (contrib/postgres_fdw/connection.c)
Date
Msg-id CAEudQAoPNkiUXvCW5etknu+=chPvm5RWiSRT+633AOrVPBGsQw@mail.gmail.com
Whole thread Raw
In response to Re: Fix misuse use of pg_b64_encode function (contrib/postgres_fdw/connection.c)  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Fix misuse use of pg_b64_encode function (contrib/postgres_fdw/connection.c)
List pgsql-hackers


Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut <peter@eisentraut.org> escreveu:
On 16.01.25 02:12, Ranier Vilela wrote:
> Per Coverity.
>
> CID 1590024:    (CHECKED_RETURN)
> Calling "pg_b64_encode" without checking return value (as is done
> elsewhere 8 out of 10 times).
>
> The function *pg_b64_encode* has in the comments:
> [0]  "and -1 in the event of an error"
>
> So, the function can fail.
> All other calls check the return, In this case it could not be different.
>
> Fix by checking the return and reporting a message to the user,
> in case of failure.

Thanks, fixed.  (I changed the ereports to elogs, which is how other
call sites do it.)
Thank you.
 

I also fixed a related problem in the pg_b64_decode() calls in libpq.

Maybe we could put a pg_nodiscard attribute on pg_b64_encode() and
pg_b64_decode()?
+1


> [0] I think the most correct would be *or* not *and* word?

I think both are ok here.
Ok.

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Amit Kapila
Date:
Subject: Re: Conflict detection for update_deleted in logical replication