2009/6/25 Jonas Maebe <jonas.ma...@elis.ugent.be>: > > On 25 Jun 2009, at 20:58, Inoussa OUEDRAOGO wrote: > >> 2009/6/25 Jonas Maebe <jonas.ma...@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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
