Em sex., 17 de jan. de 2025 às 05:11, Peter Eisentraut
escreveu:
> On 16.01.25 11:23, Ranier Vilela wrote:
> >
> >
> > Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut
> > mailto:pe...@eisentraut.org>> escreveu:
> >
> > On 16.01.25 02:12, Ranier Vilela wrote:
> > > Per Coverity.
>
On 16.01.25 11:23, Ranier Vilela wrote:
Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut
mailto:pe...@eisentraut.org>> escreveu:
On 16.01.25 02:12, Ranier Vilela wrote:
> Per Coverity.
>
> CID 1590024: (CHECKED_RETURN)
> Calling "pg_b64_encode" without checki
Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut
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_b6
On Thu, Jan 16, 2025 at 09:07:45AM +0100, Peter Eisentraut wrote:
> Maybe we could put a pg_nodiscard attribute on pg_b64_encode() and
> pg_b64_decode()?
Sounds like a good idea to me. +1.
--
Michael
signature.asc
Description: PGP signature
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
On Wed, Jan 15, 2025 at 10:12:51PM -0300, Ranier Vilela wrote:
> Fix by checking the return and reporting a message to the user,
> in case of failure.
You are right that it is inconsistent to not check the result returned
by these two calls of pg_b64_encode(), as introduced in 761c79508e7f.
Peter?
Hi.
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
