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

[Martok]

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.

Basically, a "Processor" is sort of an interpreter that first validates the
complete program and then activates the program block, "execution" in the
interpreter is not the same as actual "activation" of the user program. The
ability to save the object code (aka "compile") is completely orthogonal.
A violation is generally anything where the input does not validate as a
known-good program:

- does not depend on data:
  => generic Violation (ie. syntax error)
- depends on data:
  - decidable without computation
     => Error (Type Errors)
  - decidable with potentially complex computation
     => dynamic-violation (expression results)

Some examples from Annex D:
"""It is an error if the value of any actual value parameter is
assignment-compatibility-erroneous with respect to the type possessed by the
corresponding formal-parameter."""
=> The parameters used in a call must be compatible to the declared parameters.
This is just a static typecheck.

"""It is a dynamic-violation if the smallest value of a subrange-type is greater
than the largest value of the subrange-type when either subrange-bound is not
nonvarying or contains a discriminant-identier."""
=> The bounds can be expressions, and therefore may not be trivially obained.
The need for "compile-time" execution makes this a dynamic-violation.

"""When either dispose(q) or dispose(q,k1,...,km) is activated, it is an error
if q has a nil-value or is undefined."""
=> Requires data, but the check is trivial and in constant time, therefore it's
an error.

Note that dynamic-violation is still not necessarily a "runtime-error", just
that it cannot be validated without computation that cannot be guaranteed to be
O(1).

In any case, that only really means that a program where that can happen is not
in conformance with the abstract level of the ISO. The Processor can choose what
to do about that (paraphrased from 5.1):
a) dynamic-violation:
  1) report to the user
     continue preparation
     but: refuse execution (cf. emit a Warning in -Sew)
  2) detect at runtime
     terminate program (cf. RunError)
b) Error:
  1) same as above
  2) leave unhandled, but have a note in the documentation (wtf?)


6.9.3.5 says about the issue at hand:
"""On execution of the case-statement, the case-index shall be
evaluated. If a case-range closest-contained by a case-constant-list of a
case-list-element of the case-statement denotes that value, the statement of the
case-list-element shall be executed; otherwise, if a case-statement-completer
occurs in the case-statement, the statement-sequence of the case-statement-
completer shall be executed; otherwise, it shall be a dynamic-violation."""
(The case-statement-completer is the 'otherwise' clause)

I have opinions on what that means for when the result of "the case-index shall
be evaluated" is already in undetected violation (just apply SQL NULL-type logic
to the above), but that's not the point here.

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?


Best,

Sebastian

Am 30.07.2019 um 00:47 schrieb J. Gareth Moreton:
> Hi everyone,
> 
> So there's been an issue raised <https://bugs.freepascal.org/view.php?id=35905>
> in regards to ISO compliance with case blocks (when under $mode iso). 
> Currently, a compiler error is raised if a case block does not have exhaustive
> coverage for the input type (it's a warning on other modes).
> 
> According to ISO7185 <http://pascal-central.com/docs/iso7185.pdf>, page 55,
> section 6.8.3.5:
> 
> "On execution of the case-statement the case-index shall be evaluated. That
> value shall then specify execution of the statement of the case-list-element
> closest-containing thecase-constant denoting that value. One of the
> case-constants shall be equal to the value of the case-index upon entry to the
> case-statement; otherwise, it shall be an error."
> 
> Given it says "on execution", it implies this all occurs at run-time, especially
> as 'case-index' is usually a variable or otherwise non-deterministic at
> compile-time, hence the error should be a run-time error, not a compile-time
> error.  I think the issue is that FPC won't compile some well-known ISO Pascal
> code <https://bugs.freepascal.org/view.php?id=35859> because some of the case
> blocks don't exhaustively cover all inputs (which itself might be a sign of bad
> programming, but could be justified if said values are determined to be
> logically impossible, in which case the else blocks should contain assertions or
> internal errors).
> 
> Just interpreting the standard, I think that the error should be run-time, not
> compile-time (although definitely keep the warning).  That's just my take on it
> though.  If it is to be changed, it should be simple enough by configuring the
> 'elselabel' field to point to an error-raising routine rather than 'endlabel'
> (which occurs if there's no else block).
> 
> Gareth aka. Kit
> 
> 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> 	Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> 
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 


-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.