Indeed the wording between 7185 and 10206 has changed little, but
important: dynamic. Therefor note I still think the patch is acceptable.
I studied some more on the subject and here I will try and explain what
the actual behavior needs to be when one want to interpret the ISO 7185
case very strict.
In that case we need a different patch to solve the issue that is more
complex: suppose ISO 7185 is interpreted very strict, then one should
read it as I illustrate with three examples.
The current ISO implementation has bugs anyway. If one has to keep the
*compile time* error a patch needs to solve this type of code *without*
an error or warning:
--------------------------------------------
program testisocase1(infile,outfile);
// If compile time for iso 7185 errors are correct:
// this code currently throws a compile-time error
// and that's a bug.
// It should give no error at all and no warning at all
// After the patch there is still a- spurious - warning (small bug in
extendedpascal!)
type
operator = 3..5;
var
x:integer;
o:operator = 4;
begin
x:=1;
case o of
3 : x := x;// all
4 : x := x;// possible
5 : x := x;// cases
end;
end.
-------------------------------------------
And if ISO 7185 is interpreted to throw a compile time error, this code
should throw a compile time error:
-------------------------------------------
program testisocase2(infile,outfile);
// If compile time for iso 7185 errors are correct:
// This code should throw a compile time error with the current
interpretation
// and it does.
// But after my after the patch it throws a run-time error
// not a compile time error.
type
operator = 3..5;
var
x:integer;
o:operator = 4; // here it is an invalid value
begin
x:=1;
case o of
3 : x := x;
// 4 : x := x;// this label removed!
5 : x := x;
end;
end.
-----------------------------------------
And this code should issue just a warning:
-----------------------------------------
program testisocase3(infile,outfile);
// If compile time for iso 7185 errors are correct:
// This code should issue a warning and not a compile time error
// since the labels are in the ordinal range.
// My patch handles this case correct.
type
operator = 3..5;
var
x:integer;
o:operator = 3;
begin
x:=1;
case o of
3 : x := x;// valid
5 : x := x;// labels
end;
end.
---------------------------------------
Summary:
if current interpretation is correct, then to the best of my knowledge:
case 1 is a big bug:throws compile error on good code. Needs to be fixed
anyway.
case 2 handles correct throws compile error on value without label
case 3 is a bug throws compile error, but should issue a warning, not an
error
if ISO 10206 behavior is acceptable (which I think it is!):
case 1 handles correct, but issues a spurious warning
case 2 issues a run-time error
case 3 handles correct and issues a correct warning
The above is the exact behavior as in extendedpascal.
Note that here this code proves that that code is also not fully correct
because of the spurious warning.
On 2019-07-31 01:26, Martok wrote:
If you want something a bit more clear, try ISO/IEC 10206 (Extended
Pascal).
They split up errors and dynamic violations, which helps make the point
clearer.
The patch to switch from option a1) to a2) would be straightforward,
fix 32079
and insert a default otherwise clause that raises a RunError in -Miso.
But the
question is again, does Freepascal actually aim to be compliant with
anything,
or just have a compatible syntax and do its own thing from there?
Best,
Sebastian
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel