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

[J. Gareth Moreton]

As someone on the issue pointed out... on page 2, section 3.1:

3.1 Error

A violation by a program of the requirements of this International 
Standard that a processor is permitted to leave undetected.

NOTES

1. If it is possible to construct a program in which the violation or 
non-violation of this International Standard requires knowledge of the 
data read by the program or the implementation definition of 
implementation-defined features, then violation of that requirement is 
classified as an error. Processors may report on such violations of the 
requirement without such knowledge, but there always remain some cases 
that require execution, simulated execution, or proof procedures with 
the required knowledge. Requirements that can be verified without such 
knowledge are not classified as errors.

2. Processors should attempt the detection of as many errors as 
possible, and to as complete a degree as possible. Permission to omit 
detection is provided for implementations in which the detection would 
be an excessive burden.

----

I guess that leaves the question up in the air because FPC is reporting 
an ISO violation without knowledge of program input, but speculating 
that a particular input might not be covered.

Gareth aka. Kit

On 29/07/2019 23:47, J. Gareth Moreton wrote:
>
> 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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190730/fc7d976c/attachment.html>