Re: Error in recent pg_dump change (coverity)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Error in recent pg_dump change (coverity)
Дата
Msg-id 200605281740.k4SHe9R08155@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Error in recent pg_dump change (coverity)  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> > > Tom Lane wrote:
> > >> Hm.  But I think we'd *like* it to segfault; the idea is to make the
> > >> user's programming error as obvious as possible.  Is it worth the
> > >> trouble to just zero out the pointer members of the PGresult?
> > 
> > > There are only five of them; four need to be zeroed out.
> > 
> > Works for me.  Please commit, as I'm about to do some further work in
> > those files and would rather not have to merge ...
> 
> Done.  They were actually four, not five.  The one I mistakingly though
> was one was the notice processor hooks.
> 
> The case Martijn was saying would be warned about by the memset
> approach, setting ntuples to 0, would actually be handled as a segfault,
> because functions like check_field_number actually follow
> res.noticeHooks pointer!  ISTM we would just segfault at that point.

Agreed.  Anything to catch more errors is good.

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Error in recent pg_dump change (coverity)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Error in recent pg_dump change (coverity)