OSDN Git Service

Fix array- and path-creating functions to ensure padding bytes are zeroes.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 27 Apr 2011 17:58:36 +0000 (13:58 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 27 Apr 2011 17:58:36 +0000 (13:58 -0400)
commit18c0b4eccdc86ffb7eccc2c6facfe382537ab877
tree4a326b404dde6311bfd6906e1b18ba60d3611f40
parent348c10efe08f01872daeeb62f32c8e362fcbba69
Fix array- and path-creating functions to ensure padding bytes are zeroes.

Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits.  Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston.  We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.

Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary.  In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc.  Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix.  In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.

Back-patch to all supported branches.
src/backend/utils/adt/array_userfuncs.c
src/backend/utils/adt/arrayfuncs.c
src/backend/utils/adt/geo_ops.c