Re: [sqlsmith] Infinite recursion in bitshift
От | Merlin Moncure |
---|---|
Тема | Re: [sqlsmith] Infinite recursion in bitshift |
Дата | |
Msg-id | CAHyXU0yi9p-_Cabrqm5n7TqLCiWeQU5aET2j88BaT-gjMmszAw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [sqlsmith] Infinite recursion in bitshift (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [sqlsmith] Infinite recursion in bitshift
|
Список | pgsql-hackers |
On Fri, Oct 14, 2016 at 3:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andreas Seltenreich <seltenreich@gmx.de> writes: >> Tom Lane writes: >>> Seems sane, though I wonder if it'd be better to use -INT_MAX rather >>> than -VARBITMAXLEN. > >> I am undecided between those two. -INT_MAX might be a more precise fix >> for the problem, but the extra distance to the danger zone was kind of >> soothing :-). > > Yeah, might as well use the tighter limit. > > Poking around in varbit.c, I noticed some other places that were assuming > that a typmod couldn't exceed VARBITMAXLEN. anybit_typmodin() enforces > that, but there are places where a user can shove in an arbitrary integer, > eg > > regression=# select "bit"(42, 2147483647); > ERROR: invalid memory alloc request size 18446744073441116169 > > I fixed those too and pushed it. Thanks for the report! Curious -- are there real world scenarios where this would happen? merlin
В списке pgsql-hackers по дате отправления: