Re: Fix out-of-bounds in the function GetCommandTagName
От | Ranier Vilela |
---|---|
Тема | Re: Fix out-of-bounds in the function GetCommandTagName |
Дата | |
Msg-id | CAEudQAot64qDbctM7ztQCV3+LdqWGTVFLoFGMGAvxj8LmmtuvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix out-of-bounds in the function GetCommandTagName (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Fix out-of-bounds in the function GetCommandTagName
|
Список | pgsql-hackers |
Em dom., 14 de abr. de 2024 às 20:38, David Rowley <dgrowleyml@gmail.com> escreveu:
On Mon, 15 Apr 2024 at 11:17, Ranier Vilela <ranier.vf@gmail.com> wrote:
> Coverity has reported some out-of-bounds bugs
> related to the GetCommandTagName function.
>
> The size of the array is defined by COMMAND_TAG_NEXTTAG enum,
> whose value currently corresponds to 193.
> Since enum items are evaluated starting at zero, by default.
I think the change makes sense. I don't see any good reason to define
COMMAND_TAG_NEXTTAG or force the compiler's hand when it comes to
sizing that array.
Clearly, Coverity does not understand that we'll never call any of
those GetCommandTag* functions with COMMAND_TAG_NEXTTAG.
I think that Coverity understood it this way because when
including COMMAND_TAG_NEXTTAG, in the enum definition,
led to 193 items, and the last item in the array is currently 192.
led to 193 items, and the last item in the array is currently 192.
> Patch attached.
You seem to have forgotten to attach it, but my comments above were
written with the assumption that the patch is what I've attached here.
Yes, I actually forgot.
+1 for your patch.
best regards,
Ranier Vilela
В списке pgsql-hackers по дате отправления: