Greg Copeland <greg@copelandconsulting.net> 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
