Yea..supposedly free'ing nulls is ok...but PQclear sends a nasty error
message if a value sent to it is null...I would agree with you that it
shouldn't be that big of a deal (unless to shut up Purify) to free
nulls..In fact, we should probably patch PQclear to simply return
if result passed to it is null...
Actually, free(NULL) is not supported by all compilers so it might be
safer to make sure we're not freeing any nulls....One interesting thing to
do would be to write a C program that executes every function in libpq
repeatedly, and under Purify's watch....Sort of purity test for libpq..:)
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Mon, 2 Jun 1997, James A. Hillyerd wrote:
> On Mon, 2 Jun 1997, Igor wrote:
>
> > Well...I put these PQclear's in because there were memory leaks in that
> > area. If you put it outside, of the case statement, you start clearing
> > already freed tuples causing a mess (Marc.. that was the reason why
> > regression screwed up on boolean). Now, there are a few more memory leaks
> > (particularly with PGsettings *settings variable) but it doesn't leak much
> > and will be left alone until 6.2 probably.
> > I guess if you do if(results) PQclear (results)...oh well...There are no
> > memory leaks from PQexec anymore so might just as well leave it alone for
> > now.
> >
>
> I don't know if everything knows this or not, but free()ing a null pointer
> is valid, so it may be easier to set pointers to null after freeing them,
> then there wouldn't be much penalty in free()ing them again.
>
> I guess that is sloppy coding though. =)
>
> -james
>
> [ James A. Hillyerd (JH2162) james@blarg.net - Perl Programmer ]
> [ http://www.blarg.net/~james/ http://www.pimedia.com/ ]
> [ 1024/B11C3751 CA 1C B3 A9 07 2F 57 C9 91 F4 73 F2 19 A4 C5 88 ]
>
------------------------------
