From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | New compiler warning in jsonb_plpython.c |
Date: | 2020-01-28 00:12:46 |
Message-ID: | 21547.1580170366@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I see that buildfarm member caiman is generating a warning [1]:
jsonb_plpython.c: In function \xe2\x80\x98PLyObject_ToJsonbValue\xe2\x80\x99:
cc1: warning: function may return address of local variable [-Wreturn-local-addr]
jsonb_plpython.c:413:13: note: declared here
413 | JsonbValue buf;
| ^~~
It wasn't doing that a week or two ago when I last trawled the buildfarm
for warnings ... but this is unsurprising considering that the compiler
it's using is hot off the presses:
configure: using compiler=gcc (GCC) 10.0.1 20200121 (Red Hat 10.0.1-0.4)
The warning is from code like this:
{
JsonbValue buf;
JsonbValue *out;
...
if (*jsonb_state)
out = &buf;
else
out = palloc(sizeof(JsonbValue));
...
return (*jsonb_state ?
pushJsonbValue(jsonb_state, is_elem ? WJB_ELEM : WJB_VALUE, out) :
out);
}
so I can't say I blame gcc for being unhappy. This code is safe as long
as *jsonb_state doesn't change in between, and as long as pushJsonbValue
doesn't expect its last argument to point at non-transient storage. But
gcc doesn't want to assume that, and I don't really like the assumption
either.
I am thinking of trying to silence the warning by changing the return
to be like
return (out == &buf ?
pushJsonbValue(jsonb_state, is_elem ? WJB_ELEM : WJB_VALUE, out) :
out);
If that doesn't work, or if anyone thinks it's too ugly, I think we
should just drop the optimization of avoiding a palloc, and make
this function do a palloc always. It seems unlikely that anyone
would notice a performance difference, and the code would surely
be less rickety.
Thoughts?
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=caiman&dt=2020-01-25%2015%3A00%3A52
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-01-28 00:46:58 | Re: Remove HeapTuple and Buffer dependency for predicate locking functions |
Previous Message | Peter Geoghegan | 2020-01-27 23:01:51 | Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() |