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

[Denis Kozlov]

Result is undefined if caller passes an out of range value.

An example: TControlBorderSpacing.GetSpace(TAnchorKind(-1));

Result is indeed not initialized, so silencing this message may be harmful.

Denis


On 05/06/2017 15:22, Juha Manninen wrote:
> Wiki tells about problems the dfa encounters:
>   http://wiki.freepascal.org/FPC_New_Features_3.0#Node_dfa_for_liveness_analysis
>
> In this code if "b" is true in the first test, it will be true also in
> the second test, thus using "i" is safe and valid.
>    ...
>    if b then
>      i:=1;
>    writeln;
>    if b then
>      writeln(i);
>
> I understand that complex code can have many variations of such
> constructs and analysing them all is difficult.
>
> However for "case ... of" construct with enum types the dfa could be
> improved easily, at least I could imagine so.
> There is plenty of code like this:
>
>    function TControlBorderSpacing.GetSpace(Kind: TAnchorKind): Integer;
>    begin
>      case Kind of
>      akLeft: Result:=Left;
>      akTop: Result:=Top;
>      akRight: Result:=Right;
>      akBottom: Result:=Bottom;
>      end;
>    end;
>
> All the enum values are listed and the Result is set for sure, yet FPC
> complains:
>   controls.pp(3721,1) Warning: Function result variable does not seem
> to be initialized
>
> If the compiler used the information about all enums being present, it
> would reduce the number of dfa false positives in eg. Lazarus sources
> dramatically.
>
> Juha