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.

> 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.

>>> 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
just a few ancient C libraries (perhaps none anymore) where it'll crash.
I tend to do "if (ptr) free(ptr)" from force of habit, but I notice that
psql (among other places) relies heavily on the ANSI behavior.  It's
probably pointless to try to convince people to change that coding style.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to