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
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 ? |