Re: Missing NULL check after calling ecpg_strdup

From: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Evgeniy Gorbanev <gorbanyoves(at)basealt(dot)ru>
Subject: Re: Missing NULL check after calling ecpg_strdup
Date: 2025-07-16 11:04:12
Message-ID: CAJ7c6TP=UYNSXJ64G1TKoUv35MPaU7xpzL9_6+=ThVdj43e8xg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

> We should also force callers to take decisions
> if they always have a non-NULL input, which is what we expect from
> most of the fields extracted from the URI with strrchr().

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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2025-07-16 11:12:22 Re: Explicitly enable meson features in CI
Previous Message Michael Paquier 2025-07-16 10:58:44 Re: Fix lwlock.c and wait_event_names.txt discrepancy