[fpc-devel] Dangerous optimization in CASE..OF
Martok
listbox at martoks-place.de
Sun Jul 2 21:40:24 CEST 2017
Am 02.07.2017 um 19:47 schrieb Florian Klämpfl:
> Am 02.07.2017 um 19:29 schrieb Martok:
>> type Percentile = 1..99;
>> var I: Percentile;
>> begin
>> I:= 99;
>> inc(I); // I is now 100
>
> Forgot the mention:
> Tried with $r+ :)?
That case is also documented. RTE in {$R+}, legal in {$R-}. That also means that
while you could make assumptions about the content in {$R+} (Delphi does not*),
you definitely cannot as soon as there is a single write in {$R-}. A C++
compiler could probably try tracing that using constness of variables and
parameters, but we cannot, and so must be defensive.
*) Even FPC makes no such assumptions in all other instances!
type
TF = 1..25;
var
t: TF;
begin
t:= TF(200);
if t in [1..50] then // tautology!
Writeln('a')
else
writeln('b');
What does that print?
Yeah. As documented.
Check the codegen in R+: the if is still fully generated.
Only tcgcasenode does something else.
Honestly, I still don't understand why we're even having this discussion.
We're not talking about adding a new check - only not leaving one out that is
already there 99% of the time.
We're not talking about standardising some new behaviour - Borland did that
decades ago.
The correct behaviour is already documented in every Pascal language reference
(partly including our own), and is also the intuitive one.
I just don't get it. Why would you sacrifice the runtime safety, or, if you
prefer, the code compatibility, of your compiler over an (arguably wrong in at
least 2 modes) specific technicality of the type system that is adhered to
nowhere else?
Taking a break for now. Grading a thesis starts to sound like good relaxation.
Kind regards,
Martok
More information about the fpc-devel
mailing list