For loops with typed 'subset of integer' variables - bug?
lazarus / 62-General

----------------------------------------------------------------------
RememberTP · 2021-10-18 16:53

I was wondering why one program wasn't working: the contents of a for
loop was being executed despite the start value being higher than the
end value. If I changed the loop variable to be an integer, rather
than of a type that's a subset of integers, it worked.

The attached test program works with TurboPascal 5.5 in DOSBOX.

Output with TP:

Integers
(1,2) (1,3) (1,4)
(2,1) (2,3) (2,4)
(3,1) (3,2) (3,4)
(4,1) (4,2) (4,3)
Tinys
(1,2) (1,3) (1,4)
(2,1) (2,3) (2,4)
(3,1) (3,2) (3,4)
(4,1) (4,2) (4,3)

Output when compiled with fpc under Linux, even with -Mtp command line
option:

Integers
(1,2) (1,3) (1,4)
(2,1) (2,3) (2,4)
(3,1) (3,2) (3,4)
(4,1) (4,2) (4,3)
Tinys
(1,1) (1,2) (1,3) (1,4)
(2,1) (2,3) (2,4)
(3,1) (3,2) (3,4)
(4,1) (4,2) (4,3) (4,5)

.. i.e. the 'for' loops with the typed variables - but not integers -
are always run once.

----------------------------------------------------------------------
RememberTP · 2021-10-18 17:07

Oh, this is Free Pascal Compiler version 3.2.2+dfsg-1ubuntu2
[2021/08/20] for x86_64

https://lazarus-ccr.sourceforge.io/fpcdoc/ref/refsu58.html says

"In the case To is used, if the initial value is larger than the final
value then Statement will never be executed" and it's that which is
not happening for me with typed variables here.

----------------------------------------------------------------------
Jonas Maebe · 2021-10-18 17:12

If you compile it with range checking enabled, the program will
terminate with a range error. The behaviour of programs with range
errors in them is undefined.

----------------------------------------------------------------------
RememberTP · 2021-10-18 17:35

Mmm, true, but it could be undefined in the same way that TP handles
them if you specify -Mtp when compiling.

----------------------------------------------------------------------
Jonas Maebe · 2021-10-18 18:34

That is impossible. The meaning of "undefined" literally is "it is
impossible to define what the behaviour will be". "The same behaviour
as TP" would not be "undefined".

----------------------------------------------------------------------
Bart · 2021-10-18 20:34

Quote from: Jonas Maebe on October 18, 2021, 08:34:30 pm "The same
behaviour as TP" would not be "undefined".

That made me giggle 

Bart

----------------------------------------------------------------------
RememberTP · 2021-10-20 08:44

I meant it as a joke - obviously defining behaviour means it's not
undefined - but I still think that not following TP's behaviour when
compiled in TP mode is a bug.

If the second loop is changed to be

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i     if n >
1 then      for m := 1 to n-1 do begin        Write ('(', n, ',', m,
') ') ;        end ;     if n < NoOfLoops then      for m := n+1 to
NoOfLoops do begin        Write ('(', n, ',', m, ') ') ;        end ; 
.. it works, even with range checking on, as m is not evaluated if n
is too small / large.

----------------------------------------------------------------------
Jonas Maebe · 2021-10-20 10:43

Quote from: RememberTP on October 20, 2021, 10:44:17 amI meant it as a
joke - obviously defining behaviour means it's not undefined - but I
still think that not following TP's behaviour when compiled in TP mode
is a bug.
For correct programs, yes. For incorrect programs, no.

----------------------------------------------------------------------
PascalDragon · 2021-10-21 20:01

Quote from: RememberTP on October 20, 2021, 10:44:17 amI meant it as a
joke - obviously defining behaviour means it's not undefined - but I
still think that not following TP's behaviour when compiled in TP mode
is a bug.
If you enable range checks in TP ({$R+}) your example will fail there
as well with an error (I tested with TP 6.0). This shows that your
code is wrong in TP, too. That it does not fail without range checks
enabled is precisely the undefined behavior that Jonas spoke off.