On 05/06/17 20:37, Denis Kozlov wrote:


On 05/06/2017 18:59, Jonas Maebe wrote:
That is why I said "If range checking is off there or disabled via an explicit type cast, then the result is undefined by definition." You use an explicit typecast above.
>
> I just wanted to highlight that these cases as legal and I presume not
> uncommon, particularly if values are deserialized and typecasted.

Then this de-serialisation code must perform range checking. Again: if you assign an invalid value to a variable by typecasting, disabling range checking, inline assembly, passing a pointer to C code and overwriting the value there, or in any other way, Pascal code that works with the resulting value has undefined behaviour. The program could crash, silently fail, raise a random exception at some point, or do anything else.

> It seems that there is no way for compiler to know if the result has
> indeed being initialized by reason of enumeration of valid values,
> because one has also account for invalid values.

No, the compiler does not have to care about the fact that you may have put invalid data in that variable by bypassing the type system. If you do that, you are on your own. The compiler also uses type information to perform optimizations (e.g. "high(TAnkorKind) < Kind" will be replaced by "false" at compile time, because there is no valid program flow with which this statement can become false).

> I think that compiler should always warn (as it does now) if result is
> not initialized against all possible cases.

The DFA simply does not take into account the result of case-statements at all right now. If you have a "case bytevar of" with every possible value from 0 to 255, you will still get the warning.


Jonas
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to