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
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
