Re: Missing NULL check after calling ecpg_strdup - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Missing NULL check after calling ecpg_strdup
Date
Msg-id aHibQ8-JNIGKp2CE@paquier.xyz
Whole thread Raw
In response to Re: Missing NULL check after calling ecpg_strdup  (Aleksander Alekseev <aleksander@tigerdata.com>)
List pgsql-hackers
On Wed, Jul 16, 2025 at 02:04:12PM +0300, Aleksander Alekseev wrote:
> Hi Michael,
>
> > depending on what's set in a URI.  I think that we need to redesign a
> > bit ecpg_strdup(), perhaps by providing an extra input argument so as
> > we can detect hard failures on OOM and let ECPGconnect() return early
> > if we find a problem.
>
> Makes sense. In this case however I believe we should refactor the
> rest of the functions in src/interfaces/ecpg/ecpglib/memory.c for
> consistency. E.g. we will remove `lineno` argument and pass `bool*
> alloc_failed` and let the callers make decisions.

Or you could keep the "lineno" and the error generated in memory.c as
this gives enough details about the location where the problem
happens.  We are going to need the extra "alloc_failed".

> Since this is going to be a fairly large refactoring I would like to
> propose it as a separate patch after we agree on this one, if it works
> for you. I believe change like this deserves a separate thread for
> better visibility and also separate discussion.

Hmm.  But both are related and the same problem, no?  This is touching
the same code paths..

> Not 100% sure if I fully understand this part. Are you proposing to move:
>
>     if (string == NULL)
>         return NULL;
>
> ... check from ecpg_strdup() on the calling side, or something else?

Nope, we could keep this shortcut in ecpg_strdup() as long as there is
an extra field to track if an error has happened.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Collation and primary keys
Next
From: Dean Rasheed
Date:
Subject: Re: Improving and extending int128.h to more of numeric.c