On Wed, 2002-10-23 at 08:48, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > Okay.  I've started looking at plpython to better understand it's memory
> > needs.  I'm seeing a mix of mallocs and PLy_malloc. The PLy version is
> > basically malloc which also checks and reports on memory allocation
> > errors.  Anyone know if the cases where malloc was used was purposely
> > done so for performance reasons or simply the flavor or the day?
> 
> Probably either oversight or the result of different people's different
> coding styles.

My local copy has this changed to PLy stuff now.  Testing shows it's
good...then again, I didn't really expect it to change anything.  I'll
submit patches later.

> 
> > I thinking for starters, the plpython module could be normalized to use
> > the PLy_malloc stuff across the board.  Then again, I still need to
> > spend some more time on it. ;)
> 
> Consistency is good.  What I'd wonder about, though, is whether you
> shouldn't be using palloc ;-).  malloc, with or without a PLy_ wrapper,
> doesn't provide any leverage to help you get rid of stuff when you don't
> want it anymore.

Ya, I'm currently looking to see how the memory is being used and why. 
I'm trying to better understand it's life cycle.  You implying that even
the short term memory should be using the palloc stuff?  What about long
term?  Blanket statement that pretty much all the PLy stuff should
really be using palloc?

> 
> >>> Well, the thing that really got my attention is that dmalloc is
> >>> reporting frees on null pointers.
> >> 
> >> AFAIK that would dump core on many platforms (it sure does here...),
> 
> I have to take that back: I was thinking about pfree() not free().
> The ANSI C spec says that free(NULL) is a legal no-op, and there are

Oh really.  I didn't realize that.  I've been using the "if(  ptr ) "
stuff for so long I didn't realize I didn't need to anymore.  Thanks for
the update.  That was, of course, the cause for alarm.

> It's
> probably pointless to try to convince people to change that coding style.

Well at this late time, I think it's safe to say that it's not causing
problems for anyone on any of the supported platforms.  So I'll not
waste time looking for it even though I happen think it's a poor
practice just the same.


Thanks,

        Greg



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to