Re: guc: make dereference style consistent in check_backtrace_functions

From: Junwang Zhao <zhjwpku(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: zhanghu <kongbaik228(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: guc: make dereference style consistent in check_backtrace_functions
Date: 2026-02-26 11:04:24
Message-ID: CAEG8a3KqfVfHbHN5ZqNBmEhf9AkiccvP9GRtQRTYWad2yzWvOA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 26, 2026 at 5:21 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>
>
> > 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.

+1
The double pointer indicates an output parameter, the commit
message should be adjusted though.

>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
>
>

--
Regards
Junwang Zhao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-02-26 11:06:13 Re: SQL Property Graph Queries (SQL/PGQ)
Previous Message Álvaro Herrera 2026-02-26 10:52:40 Re: persevere NO INHERIT when Dump not-null constraints on inherited columns