Re: ARRNELEMS Out-of-bounds possible errors - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: ARRNELEMS Out-of-bounds possible errors
Date
Msg-id CAN-LCVM3-02s5K53KfQLuCiDmEDHeEzc4vBUUxcd8RHByMBPRw@mail.gmail.com
Whole thread Raw
In response to Re: ARRNELEMS Out-of-bounds possible errors  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
Hi,

The most obvious solution I see is to check all calls and for cases like we both mentioned
to pass a flag meaning safe or unsafe (for these cases) behavior is expected, like

#define ARRNELEMS(x)  ArrayGetNItems( ARR_NDIM(x), ARR_DIMS(x), false)

...

int
ArrayGetNItems(int ndim, const int *dims, bool issafe)
{
return ArrayGetNItemsSafe(ndim, dims, NULL, issafe);
}

int
ArrayGetNItemsSafe(int ndim, const int *dims, struct Node *escontext, bool issafe)
{
...

Another solution is revision of wrapping code for all calls of ArrayGetNItems.
Safe functions is a good idea overall, but a lot of code needs to be revised.

On Fri, Dec 23, 2022 at 1:20 AM Ranier Vilela <ranier.vf@gmail.com> wrote:
Em qui., 22 de dez. de 2022 às 15:45, Nikita Malakhov <hukutoc@gmail.com> escreveu:
Hi,

Actually, there would be much more sources affected, like
         nbytes += subbytes[outer_nelems];
         subnitems[outer_nelems] = ArrayGetNItems(this_ndims,
                                        ARR_DIMS(array));
         nitems += subnitems[outer_nelems];
         havenulls |= ARR_HASNULL(array);
         outer_nelems++;
      }

Maybe it is better for most calls like this to keep old behavior, by passing a flag
that says which behavior is expected by caller?
I agreed that it is better to keep old behavior.
Even the value 0 is problematic, with calls like this:

nel = ARRNELEMS(ent);
memcpy(ptr, ARRPTR(ent), nel * sizeof(int32));

regards,
Ranier Vilela


--
Regards,
Nikita Malakhov
Postgres Professional 

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Using WaitEventSet in the postmaster
Next
From: Amit Kapila
Date:
Subject: Re: Force streaming every change in logical decoding