Re: Missing NULL check after calling ecpg_strdup

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Evgeniy Gorbanev <gorbanyoves(at)basealt(dot)ru>
Subject: Re: Missing NULL check after calling ecpg_strdup
Date: 2025-07-17 06:42:11
Message-ID: aHibQ8-JNIGKp2CE@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2025-07-17 07:29:53 Re: Improving and extending int128.h to more of numeric.c
Previous Message Laurenz Albe 2025-07-17 06:30:45 Re: Collation and primary keys