On Wed, Jun 7, 2017 at 2:04 AM, Denis Kozlov <dez...@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:
type
TEnumType = (ctA, ctB);
function StrToEnum(s: string): TEnumType;
begin
case s of
"ctA": Result := ctA;
"ctB": Result := ctB;
else raise Exception.Create('Illegal TEnumType value!');
end;
end;
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.
Juha
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
