[fpc-devel] Data flow analysis (dfa) and "case ... of"

Juha Manninen juha.manninen62 at gmail.com
Wed Jun 7 16:18:04 CEST 2017

On Wed, Jun 7, 2017 at 2:04 AM, Denis Kozlov <dezlov at gmail.com> wrote:
> You suggest that only Convert3 function should raise "uninitialized result"
> warning, while Convert1 and Convert2 should not. I find this less useful,
> and, again, you can rightfully disagree, but it won't change the fact that
> it is still less useful for me (and possibly others).

Sorry but this is not a matter of opinion. Your view is just flawed and wrong.
FPC developers tried to explain that your "else" can be optimized away
and the program may crash.
The compiler trusts that data in an enum variable is legal, within the range.
It should trust the same way when doing DFA. It is logical and consistent.

If you let your enum data be out of range then your code is seriously
buggy. Why would you write such buggy code?
What you must do is add sanity checks for code that initializes enum
data based on some other data.
For example you are streaming and get data as string:

  TEnumType = (ctA, ctB);

function StrToEnum(s: string): TEnumType;
  case s of
    "ctA": Result := ctA;
    "ctB": Result := ctB;
    else raise Exception.Create('Illegal TEnumType value!');

The same way if you get integer data from I/O, you must verify the
integer is within range _before_ typecasting it.

Logical and robust.


More information about the fpc-devel mailing list