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

From Aleksander Alekseev
Subject Re: Missing NULL check after calling ecpg_strdup
Date
Msg-id CAJ7c6TP=UYNSXJ64G1TKoUv35MPaU7xpzL9_6+=ThVdj43e8xg@mail.gmail.com
Whole thread Raw
In response to Re: Missing NULL check after calling ecpg_strdup  (Michael Paquier <michael@paquier.xyz>)
List 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?



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fix lwlock.c and wait_event_names.txt discrepancy
Next
From: Nazir Bilal Yavuz
Date:
Subject: Re: Explicitly enable meson features in CI