[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
compatibility
b) Delphi compatibility
Jonas
More information about the fpc-pascal
mailing list