Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2023-03-22T03:07:15Z
Lists: pgsql-bugs
On Tue, Mar 21, 2023 at 10:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Alexander Lakhin <exclusion@gmail.com> writes:
> > 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):
>
> In that case, won't padding bytes between array elements also create
> issues?  Seems like we have to just zero the whole array area, like
> those other functions do.


Yeah, this should be the right fix, to use palloc0 instead here.  FWIW
currently in the codes there are 14 places that explicitly allocate
ArrayType, 13 of them using palloc0, the only exception is the one
discussed here.

BTW, in array_set_slice() and array_set_element() we explicitly zero the
null bitmap although the whole array area is allocated with palloc0.  Is
this necessary?

Thanks
Richard

Commits

  1. Fix oversights in array manipulation.

  2. Fix array- and path-creating functions to ensure padding bytes are zeroes.