[fpc-devel] Data flow analysis (dfa) and "case ... of"
dezlov at gmail.com
Mon Jun 5 18:46:59 CEST 2017
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.
On 05/06/2017 15:22, Juha Manninen wrote:
> Wiki tells about problems the dfa encounters:
> 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
> if b then
> 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;
> case Kind of
> akLeft: Result:=Left;
> akTop: Result:=Top;
> akRight: Result:=Right;
> akBottom: Result:=Bottom;
> All the enum values are listed and the Result is set for sure, yet FPC
> 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
More information about the fpc-devel