[fpc-devel] MinCurrency

[Jonas Maebe]

LacaK wrote on Wed, 18 Nov 2015:

>>
>>> There is also related bug report:  
>>> http://bugs.freepascal.org/view.php?id=28737
>>>
>>> And look at part of code in rtl/objpas/sysutils/sysstrh.inc:
>>>
>>> 41     {$if defined(FPC_HAS_TYPE_EXTENDED) or  
>>> defined(FPC_HAS_TYPE_FLOAT128)}
>>> 42       MinCurrency: Currency = -922337203685477.5807;
>>> 43       MaxCurrency: Currency =  922337203685477.5807;
>>> 44     {$else}
>>> 45       MinCurrency: Currency = -922337203685477.0000;
>>> 46       MaxCurrency: Currency =  922337203685477.0000;
>>> 47     {$endif}
>>>
>>> Why is for case not defined(FPC_HAS_TYPE_EXTENDED), MinCurrency  
>>> defined as is ?
>>
>> I think that on those targets, some currency handling is still (or  
>> was?) implemented via the double type (instead of fixed point using  
>> int64),
> Is there way how to check current status?
> If there is still need for conditional definition ?

You can just try to compile a test program with those constants and  
writing them. I think the problem is actually in the compiler itself.  
The constant is parsed independently of any specified type and  
therefore is parsed as a floating point constant. If the compiler is  
running on a platform that does not support the 80 bit extended type,  
the constant will be truncated at that point.

Changing the compiler to take the "currency" into account and parsing  
the number differently in that case would result in differences between

   const
     MinCurrency: Currency = -922337203685477.5807;

and

   const
     MinCurrencyConst = -922337203685477.5807;
     MinCurrency: Currency = MinCurrencySymbolicConst;

That is even worse, because then code becomes unpredictable.

> Because for example on Win64/x86_64 target, there is not defined  
> FPC_HAS_TYPE_EXTENDED, so I get "truncated values"

FPC_HAS_TYPE_EXTENDED is undefined on most platforms. It's only a very  
small minority that has it, but of course those are the most used ones.

> And secondly why is MinCurrency "-922337203685477.5807" and not  
> "-922337203685477.5808"
> (see mentioned bug report)

I don't know.


Jonas