[fpc-pascal] QWord/UInt64 and Range Check Errors

Inoussa OUEDRAOGO inoussa12 at gmail.com
Thu Jun 25 21:46:33 CEST 2009


2009/6/25 Jonas Maebe <jonas.maebe at elis.ugent.be>:
>
> On 25 Jun 2009, at 20:58, Inoussa OUEDRAOGO wrote:
>
>> 2009/6/25 Jonas Maebe <jonas.maebe at elis.ugent.be>:
>>>
>>> It's equally accurate. A hex number does not contain any sign
>>> information,
>>> so both interpretations are valid.
>>
>> so it could be parsed as QWord accurately and assigned to a QWord
>> (typed) variable without warning, as it is an assignment between two
>> QWORD values.
>
> Pascal is a context-insensitive language, which means that the type of an
> expression does not depend on the context in which it is used. The types
> always fully depend on the expression itself. Therefore the parser cannot
> parse it as "int64 or qword", it has to pick one. So a choice has to be made
> between int64 and qword, and this choice has to be the same for every usage
> of such an expression. The choice has been, from the very beginning, int64.
>
> Therefore, while the compiler could be changed to parse it as qword instead,
> it is not possible (without violating the spirit of the Pascal language and
> complicating the compiler) to make the compiler decide "this expression
> originally came from a hex value and it was possible to interpret it both as
> an int64 and a qword, and now I see it is used as a qword, so let us assume
> that the programmer meant it to represent a qword".
>
>>  * I do want to understand the basics, the fondaments of such a
>> decision ( to parsed as Int64 )
>
> The original reasons were
> a) FPC only supported int64 and no qword for a while, so when qword support
> was added the behaviour was kept the same for backward compatibility
> b) Delphi compatibility

Good and clear explanation. Thank you very much.

Best regards.
-- 
Inoussa O.



More information about the fpc-pascal mailing list