On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote:
On Wed, 31 Jul 2019 01:26:23 +0200
Martok <list...@martoks-place.de> wrote:

Of course, if you wanted a run-time error you would need to insert a run-time check, and 'some people' seemed to be hell-bent on saving these 2 cycles at any
cost.

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?

It seems to me that the problem of a lack of correspondence in a case
statement list should be of the same level of attention of the index
limits of an array, except there is no memory corruption risk. The
solution could be to insert a run time check in presence of the
switch {$R+}, if the latter is allowed in iso mode.

Greetings, Marco Borsari
No, that is not allowed in the context of the standards, but the compiler solves that already earlier in the code path and if the code is compiled with {$rangechecks on} an out of bounds will be detected. What needs to be detected if all *used* labels are within the confines of the used ordinal, but a selector without label should throw an error. In the case of my patch it behaves like extended pascal mode and throws a run-time error in that case. That is debatable in some cases, because if the selector has no label and the compiler can resolve that at compile time it should in my opinion and how I read ISO 10206 throw a compile-time error. See my remarks and test code.
Maybe you can evaluate those conclusions I made.
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to