[fpc-devel] Dangerous optimization in CASE..OF

Martok listbox at martoks-place.de
Sun Jul 2 14:14:22 CEST 2017


Am 02.07.2017 um 10:40 schrieb Michael Van Canneyt:
> These cases are without exception covered by the " unchecked (aka explicit)
> typecast," part of Jonas's statement. Including Read(File).

Aye, that was kinda my point ;)
It is really hard to write code that interacts with the outside world without
having a validation problem.
If the validation code then breaks because the compiler thinks it's clever...

Am 02.07.2017 um 10:29 schrieb Michael Van Canneyt:
> GetEnumName from typinfo will already do this for you.
> We could add an additional function that just returns true or false.
> Something as
> function ValueInEnumRange(TypeInfo : PTypeInfo; AValue : Integer) : boolean;

Enum Typeinfo is horribly broken in so many ways except for the one simple case
needed for published properties, it definitely cannot be used in its current form.


That, probably (not sure about the timeline, but it makes sense to me), is part
of the core issue: Enumeration types have become way more powerful since this
optimization was introduced. Back then, nobody would have translated a C library
enum typedef as an enumerated type - simply because we didn't have sparse enums
then. Now we do, and so it is possible to use the typesafe way -- only that it
turns out to be less safe than a byte variable and some untyped constants.





More information about the fpc-devel mailing list