[fpc-devel] [Suggestion] Enumeration range-check intrinsic
J. Gareth Moreton
gareth at moreton-family.com
Fri Jul 5 03:13:35 CEST 2019
Please don't put words in my mouth Michael or twist me up with word
play. I have never said I want to forbid the storing or communication
of enumerations, and if people start using my argument for the exact
opposite of what I'm trying to advocate and smugly say "I rest my case",
then you can have my resignation. Please clarify with me before making
such assumptions next time.
Because enumerations may take on an invalid value in these media
(there's no real way you can eliminate this possibility), you need a
reliable means to check their validity. Many of FPC's optimisations
assume that a variable of type TMyEnum is valid, so it skips
range-checking for performance reasons among others, and instructions
like "if Value < Low(TMyEnum) then" are always assumed to be False.
Sometimes even the typecasting gets shortcut so you have to be very
careful. I suggested one should not use enumerations as the only way to
get around that, which is not ideal at all, but to use enumerations on
top of Jonas' stance of essentially demanding undefined program
behaviour for invalid values is just plain dangerous for real-world
applications.
My original suggestion was to use an intrinsic like "if
IsValidEnum(Value) then" as an efficient and robust way to check if the
variable contains a valid value for the relevant enumeration, once which
won't be shortcut by the compiler's assumptions as with case blocks and
the if-statement in the last paragraph. It was then brought to my
attention that a variant had already been proposed with the "is"
operator, which in my eyes is a little bit better because it doesn't
introduce a new intrinsic that may clash with existing function names in
some projects.
But to avoid a fight or anything of the sort, given that external data
is read as an enumeration and may contain invalid data (which to give a
concrete definition, is an integer value that doesn't map to any element
in the enumeration), and it won't be caught by case blocks and can
trigger an access violation if a jump table is employed (this is how the
compiler currently behaves), what would you propose be the best solution?
Gareth aka. Kit
On 05/07/2019 01:52, Michael Van Canneyt wrote:
>
>
> On Fri, 5 Jul 2019, J. Gareth Moreton wrote:
>
>> Ah, my apologies, Michael.
>>
>> I can see the issue of it being a convenience thing, but given that
>> many programmers have fallen foul of the lack of range checking in
>> case blocks, the typecasting necessary to avoid the problem is
>> cumbersome, adds a performance penalty and, ultimately, implies you
>> should just not use enumerations at all in that instance.
>
> With this sentence you forbid storing or communicating enumerated
> values in any way: file, database, over network. It can be used only
> in a computer program and never
> leave the context of the running program under any form. Because as
> soon as
> it is somehow communicated, there is a chance it becomes invalid in
> return
> communication.
>
> Additionally you must then also abolish typecasting to an enumerated (or
> pointers to enumerated values), since that also can be a source of
> invalid
> values for an enumerated.
>
> Or are you realy advocating we write code such as
>
> Case MyInteger of
> 0 : MyEnum:=ValueOrd0
> 1 : MyEnum:=ValueOrd2;
> else
> someError
> end;
> etc, whenever an integer must be changed to an enumerated ?
>
> IMHO you would reduce the usabilty of enumerateds to almost zero by doing
> so.
>
> So you may want to reconsider, since in my experience most enumerateds at
> one point do end up outside the program and typecasts are equally
> widespread.
>
> These patterns are so ubiquitous it is worthy of an intrinsic.
>
> Michael.
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
More information about the fpc-devel
mailing list