Hi,
On 2025-04-25 15:58:29 -0400, Andres Freund wrote:
> On 2025-04-25 13:37:15 -0400, Tom Lane wrote:
> > Buildfarm member serinus has been producing the identical warning for
> > some time. I'd been ignoring that because it runs "experimental gcc",
> > but I guess the experiment has leaked out to production distros.
> >
> > What seems to be happening here is that after inlining
> > assign_simple_var into exec_set_found, the compiler decides that
> > "newvalue" might be zero (since it's a BoolGetDatum result),
> > and then it warns -- in a rather strange way -- about the
> > potential null dereference.
>
> I don't think it actually is complaining about a null dereference - it thinks
> we're interpreting a boolean as a pointer (for which it obviously is not wide
> enough)
>
>
> > The dereference is not reachable
> > because of the preceding "var->datatype->typlen == -1" check,
> > but that's not stopping the optimizer from bitching.
>
> > I experimented with modifying exec_set_found thus:
> >
> > var = (PLpgSQL_var *) (estate->datums[estate->found_varno]);
> > + Assert(var->datatype->typlen == 1);
> > assign_simple_var(estate, var, BoolGetDatum(state), false, false);
> >
> > which should be OK since we're expecting the "found" variable to
> > be boolean. That does silence the warning, but of course only
> > in --enable-cassert builds.
>
> One way to address this is outlined here:
>
> https://postgr.es/m/20230316172818.x6375uvheom3ibt2%40awork3.anarazel.de
> https://postgr.es/m/20240207203138.sknifhlppdtgtxnk%40awork3.anarazel.de
>
> I've been wondering about adding wrapping something like that in a
> pg_assume(expr) or such.
I've been once more annoyed by this warning. Here's a prototype for the
approach outlined above.
Greetings,
Andres Freund
