| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | zhanghu <kongbaik228(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: guc: make dereference style consistent in check_backtrace_functions |
| Date: | 2026-02-26 09:21:13 |
| Message-ID: | 08805314-299A-4941-B63E-4CC3E144E0E7@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Feb 26, 2026, at 15:03, zhanghu <kongbaik228(at)gmail(dot)com> wrote:
>
> Hi,
>
> In check_backtrace_functions(), most accesses to the input string follow the pattern (*newval)[i]. However, the empty-string check is currently written as:
>
> if (*newval[0] == '\0')
>
> While functionally correct due to how the compiler handles the address-of-address context here, this form is semantically misleading. It relies on implicit operator precedence rather than explicit intent.
>
> The attached patch rewrites it as:
>
> if ((*newval)[0] == '\0')
>
> This change ensures semantic clarity and maintains a consistent dereferencing style throughout the function. No functional changes are introduced.
>
> Regards,
> Zhang Hu
> <v1-0001-guc-make-dereference-style-consistent-in-check_ba.patch>
This is an interesting find.
[] has higher precedence than *, so:
- (*newval)[i] means to get the first string, then get the char at position i
- *newval[i] means to get the array element at position i, then get the first char
When i is 0, (*newval)[0] and *newval[0] happen to yield the same result, so this isn't a functional bug.
However, in the GUC context, newval is a point to a string rather than a two-dimension char array, *newval[i] is meaningless, so +1 for fixing this to improve readability.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jakub Wartak | 2026-02-26 09:25:47 | Re: Add errdetail() with PID and UID about source of termination signal |
| Previous Message | Ashutosh Sharma | 2026-02-26 09:11:42 | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |