[Fwd: Re: [Harbour] Problem with return of LoadLibrary and Harbour 11047]

[Szakáts Viktor]

>>    In my code in cases like this I return NIL instead of NULL  
>> pointer. This
>>    is better for future compatibility, if we are going to change to
>>    collectible pointers in the future. Since the value of the  
>> collectible
>>    pointer will not be NULL.
>> My vote goes to returning same type for both error and success  
>> cases. Anyhow "Empty( retval )" is working for both cases, so it  
>> seems the "best practice" when validating such return values.
>
> We can not return empty collectible pointer! So, simple NULL pointer  
> instead of collectible is also a kind of different type. Well, both  
> has VALTYPE() == "P", but in C code it looks like different type:

You're right, but in this case I used to return hb_retptr( NULL ), which
is also "P" type, but non-collectible. Hard to tell which is better.
Problem creep in probably as soon as we start to have collectible
*typed* pointers, because in this case we may not be able to keep the
type while returning NULL, but the same is the problem with NIL,
maybe NIL is slightly cleaner here, as it doesn't suggest anything
more than just being empty.

>
> HB_FUNC( AAA )
> {
> if( somefunc() == OK )
>   hb_retptrGC( ... );
> else
>   hb_retptr( NULL );
> }
>
> HB_FUNC( BBB )
> {
>   some* pPtr = hb_parptrGC( ..., 1 );
>
>   // If AAA returned NULL, here we do not have a valid GC pointer
>   // just like invalid type was passed...
>   if( pPtr )
>      ....
>   else
>     hb_errRT_BASE_SubstR( EG_ARG, 3012, NULL, HB_ERR_FUNCNAME,  
> HB_ERR_ARGS_BASEPARAMS );
> }
>
>
> All above does not mean we need NIL instead of NULL pointer, but  
> difference is minor. Sometimes it is even better to have NIL, for  
> example: printed error log is more clear if you see NIL as parameter  
> instead of <POINTER> parameter, if we do not see pointer value  
> explicitly.

Yes.

> One of the reason why I am writing this letter without having the  
> strong opinion NIL vs. NULL is future extension of pointers. Przemek  
> has some ideas about extending pointers to support methods. Maybe  
> EMPTY() should be a kind of overloadable method/operator and every  
> class (including pointers) can have EMPTY() overloaded. This gives  
> possibility to test EMPTY() for varios classes/pointer. In this case  
> we can use return value of exactly same type. So, one more vote  
> "EMPTY()".
>
> Summary: I would be nice, if we can see (or think about) a future  
> extensions to decide some "no important" things like NIL vs. NULL  
> today.

I agree. No strong opinion here on either side yet, so far I used to  
use NULL in practice.

So far conclusion is that callers should use Empty().

Brgds,
Viktor