Re: Error in recent pg_dump change (coverity)

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Error in recent pg_dump change (coverity)
Date: 2006-05-28 17:38:32
Message-ID: 20060528173832.GC15766@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-05-28 17:40:09 Re: Error in recent pg_dump change (coverity)
Previous Message Tom Lane 2006-05-28 17:07:06 Re: Error in recent pg_dump change (coverity)