Am 02.01.2019 um 11:30 schrieb Florian Klämpfl: > The compiler is for speed reasons not compiled with $R+/$O+, so the safety > else clause have its purpose, but they should > throw an internal error instead. And here we are at that other issue again. There is absolutely no guarantee the safety clause is even present in the compiled ppc. The improved jumptable generation actually makes it less likely! (the state of $R,$O doesn't change this)
So there's really 2 possible goals: - safety against programmer error: a new stringtype is invented, and not considered here. The coverage warning will tell the programmer, just as an IE (maybe) would during testing -- it's a bug either way. - safety against data error: def deserialized from damaged ppu? Undefined behaviour, the else clause may not be present in the compiler binary, since all legal values are handled. Which is exactly what the Unreachable Code warning would tell you. This segment of the compiler is specifically the kind of scenario that these warnings are designed to catch, and also the reason why they are warnings, not hints. Code that someone wrote and language spec do not agree, and the compiler will do something that is *very likely* unintended. -- Regards, Martok _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel