Re: Avoid overflow with simplehash
От | Ranier Vilela |
---|---|
Тема | Re: Avoid overflow with simplehash |
Дата | |
Msg-id | CAEudQAp27pPfDkbwM5A1btAqtR6yZWbiN4h1206edV-ZvyTURw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoid overflow with simplehash (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: Avoid overflow with simplehash
Re: Avoid overflow with simplehash |
Список | pgsql-hackers |
Em qui., 6 de jul. de 2023 às 11:37, Daniel Gustafsson <daniel@yesql.se> escreveu:
> On 6 Jul 2023, at 16:28, Ranier Vilela <ranier.vf@gmail.com> wrote:
> The function SH_START_ITERATE can trigger some overflow.
>
> See:
> typedef struct SH_ITERATOR
> {
> uint32 cur; /* current element */
> uint32 end;
> bool done; /* iterator exhausted? */
> } SH_ITERATOR;
>
> The cur field is uint32 size and currently can be stored a uint64,
> which obviously does not fit.
- Assert(startelem < SH_MAX_SIZE);
+ Assert(startelem < PG_UINT32_MAX);
I mighe be missing something, but from skimming the current code, SH_MAX_SIZE
is currently defined as:
#define SH_MAX_SIZE (((uint64) PG_UINT32_MAX) + 1)
This is Assert, that is, in production this test is not done.
See the comments:
"Search for the first empty element."
If the empty element is not found, startelem has PG_UINT64_MAX value,
which do not fit in uint32.
Can you see this?
regards,
Ranier Vilela
В списке pgsql-hackers по дате отправления: