[Harbour] itemGetNL & dates

[Mindaugas Kavaliauskas]

>> hb_itemGetNL() is implemented to return Julian date value instead of 0. 
>> Why? (IMHO, date is not numeric and hb_itemGetDL() should be used)
> 
> I do not know. Probably for some historical reasons. In Clipper the
> result of _itemGetNL( pDateItm ) is undefined and tests confirm it.
> But _parnl( iParam ) seems to return Julian date when iParam is date
> item. Probably some of conversions we have in hb_itemGet*() functions
> are used to emulate unprotected access to ITEM internals in Clipper
> in _itemGet*() functions. But I cannot say which ones and which were
> added by Harbour developers as some type of Harbour extensions.

Hi,


I've check Clipper. It seems _itemGetNL() always return value and does 
not checks item's type at all. It returns object manager handle for 
strings, arrays and codeblocks, ds segment offsets (in low word of 
return value) for references and also half (4 bytes) of 8 byte double 
value. In our language _itemGetNL() is:
   LONG hb_itemGetNL( PHB_ITEM pItem )
   {
      return ( LONG ) pItem->item.asLong.value;
   }

_parnl() returns numeric values for long, date and double types and 0 
otherwise.


My problem was that I've used code:
   l = hb_itemGetNL( pItem );
instead of
   if ( HB_IS_NUMERIC( pItem ) )
   {
      l = hb_itemGetNL( pItem );
   }
   else
   {
      l = 0;
   }
hoping that return value is 0, if item type is not numeric. But it is 
not true for the dates.

I can live with it, but I would support removing Julian date value 
return from hb_itemGetNL() and hb_parnl() to make Harbour implementation 
more correct and error resistant. Clipper was using those functions for 
dates because there were no _itemGetDL() and _pardl() in Clipper. We 
have special function for the dates, so, there is no need to emulate 
side effects of Clipper.

It would be nice to hear other opinions.


Best regards,
Mindaugas