[fpc-devel] Minor debate with ISO standard on case blocks

[Marco Borsari]

Il 31/07/2019 08:37, thaddy ha scritto:
> On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote:

> 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.

I read your code examples and I have to admit I was a little bit 
confused about the actual discussion: I was concerned only for the 
situation in which the value of variable does not match the case 
statement list, irrespectively of the ordinal type of the variable.
For the latter I have no idea about what should be desiderable to do
nor knowledge about standards.

 > I just compiled pascal-s (Moore's iso version, because that's the
 > relevant one) but did not run it yet with my patch. It fails at
 > run-time or compile-time?
 > It is an interpreter/p-code system, so has a greater level of freedom.
 > Note iso7158 is based on Wirth's but Wirth's version is not
 > iso compliant.

For the situation I intended before, it raises an error when it executes 
the object code, please consider this code fragment of the procedure 
interpret:

12: begin (* switch *) h1 := s[t].i; t := t-1;
        h2 := ir.y; h3 := 0;
        repeat if code[h2].f <> 13 then
            begin h3 := 1; ps := caschk
            end else
          if code[h2].y = h1 then
            begin h3 := 1; pc := code[h2+1].y
            end else
          h2 := h2 + 2
        until h3 <> 0
      end;

ps is set to caschk when all labels are been processed without a match
and the processor reaches code 13, i.e. the end of case.
I hope to be more near to the point this time,
Marco