Waldek Hebisch wrote:

Adriaan van Os wrote:

...

...

• 20060130: In ISO modes report out of range constants only at runtime (range1.pas)

{$W-} {$classic-pascal} program range(Output); var v : 1..2; begin if true then writeln('OK') else v := 0 end.

I welcome the change, but it implies that no checking is done when --range-checking is off (but currently it does).

{$W-} {$classic-pascal} program range2(Output); var v : 1..2; begin {$local R-} v := 0; {$endlocal} writeln('OK') end.

I suggest this behaviour for --mac-pascal (also).

What do you mean by "it implies ...". For me your program gives range error. If it does not give an error to you that would mean a bug in the compiler.

I wrote "implies" because to me --no-range-checking (or $R-} implies no-range-checking. And for whatever reasons.

I have mixed feelings after your message. Namely, the change was mostly motivated by standard compliance. AFAIU a program is considered legal if it does no range violations at runtime, which means that it _may_ contain range violating constants in dead code. My first reaction was was that such violatins are latent bugs (and I still think that such reaction is apripriate for most of the code). But there are some real uses of dead code:

1. parametized programs, when changing constants can make code both reachable and valid
2. mechanically generated code, where code generator inserts its own range checks before real code

So I think that it may be of some use to have a separate option which defers range-checking to runtime.

Definitely.

OTOH turning range checking off is intened to speed up correct programs.

Other reasons to disable range checking (than speed) can be

* needed (locally) for signed/unsigned type-casts (see http://www.gnu-pascal.de/crystal/gpc/en/mail12391.html) * needed when working e.g. with variable-size arrays that cannot be schemata (for ABI reasons), for example

TextRangeArray = record fNumOfRanges: SInt16; fRange: array [0..0] of TextRange; end;

(also see http://www.gnu-pascal.de/crystal/gpc/en/mail9120.html).

For programs which violate ranges you get (in C linguo) undefined behaviour. Look at the following:

{$W-} {$classic-pascal} var v1, v2 : 1..2; begin {$local R-} v1 := 0; {$endlocal} v2 := 1; if v1 + v2 < 2 then writeln('v1 was below its range') else writeln('legal program can take only this branch') end.

What result do you expect? ATM this program is "optimized" into call to runtime procedure which reports range check violations (and with trurly variable `v1' the test is done at runtime). However, in the program above optimizer is allowed to replace the `if' instruction by the second branch. So in principle you may get completly unpredictable results. In the program above gpc generats what one would naively expect. But even now we do remove some comparisons based on declared ranges (I belive that we do this only in range checks...). Together with backend optimizatins this potentially can change the program quite a lot.

Yes, but in the end a program is the responsibility of the programmer. Even if $R- can be misused (as anything on this earth) that shouldn't be a reason to forbid it for constants. I mean, if we want to forbid it for constants, than we have to forbid $R- altogether -- and a lot more, dangerous things like pointers for example. Can we make sure that a programmer doesn't do anything stupid ? We can't.

But it's an old discussion point (and we don't want to discuss the same things again and again).

Regards,

Adriaan van Os