Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls - Mailing list pgsql-bugs

From Alexander Lakhin
Subject Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls
Date
Msg-id 4240d86f-7e9f-388b-fd96-f8944860c0f5@gmail.com
Whole thread Raw
In response to Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hi Richard,
21.03.2023 14:52, Richard Guo wrote:
Nice catch.  This can also be seen on master.

I searched the codes a little bit and found that in array_set_slice()
and array_set_element() the 'newarray' is allocated with palloc0 and
then the nulls bitmap is zeroed with

 MemSet(nullbitmap, 0, (nitems + 7) / 8);

if havenulls is true.  I wonder if we can do the same here.

I'm afraid that zeroing only bytes behind nitems bits is not enough, as outDatum() doesn't bother to calculate the exact size of nulls bitmap, it just outputs all bytes of a datum (40 bytes in that case):
   length = datumGetSize(value, typbyval, typlen);
...
            for (i = 0; i < length; i++)
               appendStringInfo(str, "%d ", (int) (s[i]));

Best regards,
Alexander

pgsql-bugs by date:

Previous
From: Tianyi Gao
Date:
Subject: operator class "xxx" does not exist for access method "yyy"
Next
From: Tom Lane
Date:
Subject: Re: BUG #17859: Suspected collation conflict when using recursive query