Potential for bugs while using COPY_POINTER_FIELD to copy NULL pointer

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Potential for bugs while using COPY_POINTER_FIELD to copy NULL pointer
Date: 2012-04-09 11:19:59
Message-ID: CAFjFpRcL3fPB2V3+k4=HqC87hbKFobJhXWztbEUqSKYB_fLwPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
COPY_POINTER_FIELD is defined as -
61 #define COPY_POINTER_FIELD(fldname, sz) \
62 do { \
63 Size _size = (sz); \
64 newnode->fldname = palloc(_size); \
65 memcpy(newnode->fldname, from->fldname, _size); \
66 } while (0)

Since we allocate _size memory irrespective of whether from->fldname is
NULL, every NULL pointer can get copied as non-NULL pointer because the way
*alloc routines handle 0 sizes.
-- from man malloc
If size is 0, then malloc() returns either NULL, or a unique pointer
value that can later be successfully passed to free()
--

After such a copy tests like if (pointer) will start failing. There are few
callers of COPY_POINTER_FIELD which do not call the macro if the size can
be 0. But there are some who do not do so. This looks fishy, in case we
have if (pointer) kinds of cases.

Shouldn't COPY_POINTER_FIELD return NULL, if the pointer to be copied is
NULL?
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Clover White 2012-04-09 11:38:46 why was the VAR 'optind' never changed in initdb?
Previous Message 乔志强 2012-04-09 10:33:06 [streaming replication] 9.1.3 streaming replication bug ?