Re: Fix misuse use of pg_b64_encode function (contrib/postgres_fdw/connection.c)

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix misuse use of pg_b64_encode function (contrib/postgres_fdw/connection.c)
Date: 2025-01-16 08:07:45
Message-ID: c081a0ba-6f53-4c48-8860-211804a58879@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.)

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()?

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

I think both are ok here.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2025-01-16 08:18:18 Re: Eager aggregation, take 3
Previous Message jian he 2025-01-16 07:58:48 Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW