From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Xing Guo <higuoxing(at)gmail(dot)com> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Junwang Zhao <zhjwpku(at)gmail(dot)com> |
Subject: | Re: Don't pass NULL pointer to strcmp(). |
Date: | 2023-11-02 01:57:18 |
Message-ID: | 2943279.1698890238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Hmm ... if we're doing it ourselves, I suppose we've got to consider
> it supported :-(. But I'm still wondering how many seldom-used
> code paths didn't get the message. An example here is that this
> could lead to GetConfigOptionResetString returning NULL, which
> I think is outside its admittedly-vague API spec.
After digging around for a bit, I think part of the problem is a lack
of a clearly defined spec for what should happen with NULL string GUCs.
In the attached v3, I attempted to remedy that by adding a comment in
guc_tables.h (which is maybe not the best place but I didn't see a
better one). That led me to a couple more changes beyond what you had.
It's possible that some of these are unreachable --- for example,
given that a NULL could only be the default value, I'm not sure that
the fix in write_one_nondefault_variable is a live bug. But we ought
to code all this stuff defensively, and most of it already was
NULL-safe.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Don-t-use-strcmp-with-nullable-pointers.patch | text/x-diff | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2023-11-02 02:03:35 | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |
Previous Message | Nathan Bossart | 2023-11-02 01:52:39 | Re: GUC names in messages |