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-12 03:23:07
Message-ID: aHHVG6fEopTeHVFU@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 11, 2025 at 07:22:36PM +0300, Aleksander Alekseev wrote:
> The patch looks correct, but I believe it's incomplete. It misses
> several other places where ecpg_strdup() is called without proper
> checks. A correct patch would look like the one attached.
>
> While working on it I noticed a potentially problematic strcmp call,
> marked with XXX in the patch. I didn't address this issue in v2.
>
> Thoughts?

The semantics that I'm finding really annoying is the fact that
ecpg_strdup() is OK to assume that a NULL input is valid to handle, so
there is no way to make the difference between what should be an
actual error and what should be valid, leading to more confusion
because "realname" can be NULL.

Should we actually check sqlca_t more seriously if failing one of the
strdup calls used for the port, host, etc. when attempting the
connection? The ecpg_log() assumes that a NULL value equals a
<DEFAULT>, which would be wrong if we failed one of these allocations
on OOM.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florents Tselai 2025-07-12 04:07:08 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Previous Message Michael Paquier 2025-07-12 01:29:42 Re: pg_logical_slot_get_changes waits continously for a partial WAL record spanning across 2 pages