Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group