Frank Heckenbach wrote:
Waldek wrote (in private mail, but I hope you don't mind me forwarding it to the list, as it concerns the current discussion about bitsizes):
I have noticed that fjf395[ab].pas expects to be able to compute on out of range values. Both of them fail with 4.1 backend. According to recent discussion on GCC list using out of range values is illegal (if we consider such values legal the type should have bigger bounds).
I would prefer to declare fjf395[ab].pas illegal and remove them from the testsuite. And say that user programs expecting such behaviour should be fixed.
Yes, the test programs are currently wrong as they put ordinal values > 1 in `Boolean attribute (Size = n)' variables. I wrote them at a time when semantics of `Boolean (n)' (as they were called back then) were not very clearly defined ...
The other solution is "double accounting", when we have types with loose bounds for backend use, but we separatly track ranges in the front end.
I'd prefer to avoid this, as it'd surely add quite some effort for probably little gain. In fact, as integer ranges can be freely declared, and we don't (yet) support bitsizes for types other than integers and Booleans, it seems to affect only Booleans with specified bitsize, which is a very special case.
So we have the choice either to leave the range at False {0} .. True {1}, and forbid other values, and change the test programs,
In my opinion, the only correct option.
or to really declare the range according to the bitsize (e.g. False {0} and 255 values of True for an 8 bit type).
The former would seem more Pascalish. OTOH, such types are probably often used for C interfaces, and what will happen if C routines put values > 1 in them?
Use an integer or cardinal type instead (for example in the Win32 API, but that API is a mess anyway, dependent on the call you have to check for <> 0 or = 0 or <> 1 or =1).
Regards,
Adriaan van Os