Le 26/04/2013 21:33, Phil Nelson a écrit :

On Friday 26 April 2013 12:01:34 pm Jonas Maebe wrote: I also verified that a very old version of gcp (2.95.3) did not cause a range error on this kind of construct.

old versions of *GPC* had not implemented range check. What was the *GPC* (not *GCC*) version of that compiler ?

Maurice

On 26 Apr 2013, at 22:22, Waldek Hebisch wrote:

...

Hi,

Can anyone here offer some insights regarding the standard conformance of the test program submitted at http://bugs.freepascal.org/view.php?id=24318 ? (range.p)

Both FPC and GPC cause the program to abort with a range check error, while the submitter is of the opinion that the for-loop should merely short-circuit and never executed instead.

AFAICS he is right. ISO-10206 clause 6.9.3.9.2 says:

: The initial-value and the final-value of a sequence-iteration : of an iteration-clause of a for-statement shall be of a type : compatible with the type of control-variable of the for-statement. : The initial-value and the final-value shall be : assignment-compatible with the type possesed by the : control-variable if the statement of the for-statement : is executed.

Compatible type for integer subrange means that any integer value is OK. Assignment-compatible means that values must be in range, but is only required when loop body is actually executed.

The for-statement includes the initial-value assignment to the control-variable and the comparison of the control-variable with the final-value. That part of the for-statement is executed any time the control flow of the program reaches the for-loop. That's why I believe that the assignment-compatibility rule applies.

Jonas

Le 27/04/2013 20:47, Waldek Hebisch a écrit :

BTW2: In Pascal expressions are normally computed using "full" types and range restrictions only play role for assignment. The "equivalent" code will perform assignment to control variable only when body will be execute.

This is how gpc should work, but not how it actually works with current gpc version (20070904 with either 3.4.5 or 4.3.5 gcc backends). To check a suggestion of Florian Kaempfl on the fpc bug list about signed/unsigned underlying type, I changed ttlow to -1 to be sure that the underlying "full" type is integer, not cardinal, and put ttop - 2 for the upper limit of the loop, which is out of bounds for assignment, but not for the underlying integer type, giving ------------------------------------------------------------------ program range ( output );

const ttlow = -1; tthigh = 800;

type ttx = ttlow .. tthigh;

var ttop : ttx;

procedure p ( low : ttx ); var high : ttx; begin for high := low to ttop - 2 do writeln( high, ' ', low, ' ', ttop, ' ', ttop - 1 ); end;

begin ttop := 0; p( 1 ); end. -------------------------------------------------------------------- I obtain the following out of bounds message:

MinGW: C:\Lombardi\mingw\gpc\bugRange>range range: value out of range (error #300 at 40131d)

So the assignment of high:=ttop-2 has been done, even if the loop is not executed.

Maurice

On 27 Apr 2013, at 20:47, Waldek Hebisch wrote:

[snip]

BTW4: The reporter wrote this clearly in the comment to the FPC bug report...

The poster was obviously heavily invested in getting his code accepted by FPC. Given that GPC is known for its standards compliance and had the same behaviour as FPC, and given the fact that as a non-standards-expert I did not know that for-statement always solely refers to "loop body", I thought the standard was possibly in part self-contradicting or ambiguous (it wouldn't be the first such standard). That's why I asked here rather than just closing the bug report and be done with it, because I knew there are people here who know way more about the Pascal standard than I do.

Jonas