Can't use psFree as a function pointer tor psDlistFree, etc.

[robert.desonia@…]

Serious oversite here.

psDlistFree (as well as the free for vectors of pointers, etc.) takes a function
pointer of the form 'void (*fcn)(void*)', which is a void function that takes a
single void* parameter (i.e., same as C's free).

The problem is this: one would think the logical function one might use is
psFree, but psFree is a macro to a multi-parameter function so that it can grab
the file and line # of the caller.

I don't see a clean solution to allowing psFree to be used by these functions.
The few obvious things are:

1. wrap p_psFree with another function that gives the proper prototype,
2. create a special value (e.g., PS_FREE = (void*)1) that would tell Dlist to

use psFree directly, or

3. remove file and lineno from psFree (probably not a desired solution).

-rdd

[robert.desonia@…]

To get things rolling, I implemented the special value 'PS_FREE' option listed
for DList. I can easily remove that or expand it to other functions with the
same problem.

For example, to use psFree for psDlistFree, the syntax would be like:

psDlistFree(list,PS_FREE);

It probably wouldn't hurt if there was eventually a PS_* defined for all of the
psLib free functions that could be used.

[eugene]

solution 2 seems to me like the right solution, at least for now. there is a
slightly ambiguous point here which the memory management scheme does not
address very well: which file/lineno in the levels of the psFree/psAlloc steps
are actually of interest? Since most memory alloc/free functions are actually
taking place in psFooAlloc/psFooFree type functions, there is not so much
information being carried by the file/lineno data invoked at the psAlloc/psFree
level. it might have been better to carry the file/lineno information
explicitly in the function call, and have all of the psFooAlloc/psFooFree
functions have those arguments. In such a case, the psFooAlloc/Free functions
would pass their lineno/file arguments down to the psAlloc/Free functions.

Let's keep the solution you have used, but continue to discuss it further

[eugene]

we've decided to carry a pointer to the destructor in the psMemBlock.