[fpc-devel] [Suggestion] Enumeration range-check intrinsic

J. Gareth Moreton gareth at moreton-family.com
Thu Jul 11 15:46:41 CEST 2019


On 11/07/2019 13:07, Michael Van Canneyt wrote:
> There is no "disagreement". just doubt as to what the right approach is.
>
> If the compiler assumes that an enumerated always contains a valid value,
> then the logical consequence is that the above "is" always evaluates to
> true. In that case it makes sense to downright forbid the construct, 
> as it
> only makes sense if MyEnumValue is another ordinal type.
>
>
> The case of bitpacked values and variant records shows that the language
> allows for cases where this assumption is maybe not correct. From this 
> point
> of view, the above construct is a valid check and should not be optimized
> away.
>
> It now depends on your point of view what road to take.
>
> Michael.

Well, the patch ("AS-IS-enum-10.patch") was made on the assumption that 
"MyEnum is TMyEnum" will do a range check and return False if it's out 
of bounds.

Outside of typecasting, there isn't a reliable way to check if an enum 
contains a valid value, which leads to the problem of reading an enum 
from an external source that may be tampered or corrupted.  I had the 
impression that "as" and "is" would be a reliable sanity check to see if 
the enum is in bounds.

For my personal point of view, I would like these operators to be the 
exception to the rule of the compiler assuming an enum always contains a 
valid value, and above all, the documentation improved for "case" that 
advises the programmer to use the operators if they are using 
enumerations and there's a chance the input may be invalid.  Whatever 
decision is made though, I do think there should be a warning in the 
documentation and a suggested workaround just so we don't keep getting 
bug reports.

I'm not on the core team though, so the final decision ultimately 
doesn't rest on me, but for what it's worth, I would like "MyEnum is 
TMyEnum" to not assume the answer is True and to actually perform an 
explicit check.  However, there is an argument to be made for both 
approaches.

Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



More information about the fpc-devel mailing list