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

Jonas Maebe jonas.maebe at elis.ugent.be
Thu Jun 25 21:39:50 CEST 2009

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  
b) Delphi compatibility


More information about the fpc-pascal mailing list