Re: libpq: Remove redundant null pointer checks before free()

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq: Remove redundant null pointer checks before free()
Date: 2022-06-19 09:55:33
Message-ID: 20220619095533.7u35bbei3a2sswdm@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-Jun-17, Peter Eisentraut wrote:

> From 355ef1a68be690d9bb8ee0524226abd648733ce0 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut <peter(at)eisentraut(dot)org>
> Date: Fri, 17 Jun 2022 12:09:32 +0200
> Subject: [PATCH v2 3/3] Remove redundant null pointer checks before PQclear
> and PQconninfofree
>
> These functions already had the free()-like behavior of handling NULL
> pointers as a no-op. But it wasn't documented, so add it explicitly
> to the documentation, too.

For PQclear() specifically, one thing that I thought a few days ago
would be useful would to have it return (PGresult *) NULL. Then the
very common pattern of doing "PQclear(res); res = NULL;" could be
simplified to "res = PQclear(res);", which is nicely compact and is
learned instantly.

I've not seen this convention used anywhere else though, and I'm not
sure I'd advocate it for other functions where we use similar patterns
such as pfree/pg_free, so perhaps it'd become too much of a special
case.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-06-19 17:38:31 Re: libpq: Remove redundant null pointer checks before free()
Previous Message Tom Lane 2022-06-19 04:56:13 Re: 15beta1 tab completion of extension versions