Hi Xavi,
> IMHO the next changes in the functions hb_parptrGC and hb_itemGetPtrGC .-
>
> void * hb_parptrGC( const HB_GC_FUNCS * pFuncs, int iParam )
> {
> ...
> if( HB_IS_POINTER( pItem ) && pItem->item.asPointer.collect )
> {
> if( pFuncs )
> return (hb_gcFuncs( pItem->item.asPointer.value ) == pFuncs ?
> pItem->item.asPointer.value : NULL);
> else
> return pItem->item.asPointer.value;
> }
> }
>
> return NULL;
> }
>
> ...
>
> Allows return generic GCs calling functions with pFuncs parameter to NULL.
> As they are functions of our public API, IMO this facilitates development of
> libraries because may happen that the address of function is unknown or
> static but we are interested in having the GC pointer.
>
> For example .-
> One possible implementation in wapi_par_HANDLE because the HANDLE can be
> pointer plane, GC or GC external (address of function is unknown, static),
> could be .-
>
> HANDLE wapi_par_HANDLE( int iParam )
> {
> void ** ph = ( void ** ) hb_parptrGC( NULL, iParam );
>
> return (ph ? ( HANDLE ) *ph : ( HANDLE ) hb_parptr( iParam ));
> }
>
> What do you think about this?. Comments.
To me this seems to defeat the purpose of this API at all,
since the whole point here is that we guarantee that
we know what kind of pointer we're dealing with at all,
and we don't just pass this pointer in the wild, because
it can cause all sort of problems (GPF due to missed
reference counting and leaks due to missed freeing).
The case where pFunc is NULL seems to be covered already
by existing pure hb_parptr() (and friend) functions.
You can already pull the raw pointer in such cases
by simply calling hb_parptr() on a GC collected
pointer, but I find this very bad practice and it's
in fact marked as a TOFIX even in HBQT, the only place
where such hack is done in Harbour. This part is highly
likely be responsible for many of the experienced leaks.
I don't know what would be a clean solution to allow
mixed types of pointers while keeping GC collection,
but I'd certainly leave this API in its current pure
state.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
