<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>As someone on the issue pointed out... on page 2, section 3.1:</p>
    <p><span style="left: 120px; top: 435px; font-size: 15px; transform:
        scaleX(1.06956);">3.1 Error</span></p>
    <p><span style="left: 120px; top: 435px; font-size: 15px; transform:
        scaleX(1.06956);">A violation by a program of the requirements
        of this International Standard that a processor is permitted to
        leave undetected.</span></p>
    <p><span style="left: 120px; top: 435px; font-size: 15px; transform:
        scaleX(1.06956);">NOTES</span></p>
    <p><span style="left: 120px; top: 435px; font-size: 15px; transform:
        scaleX(1.06956);">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.</span></p>
    <p><span style="left: 120px; top: 435px; font-size: 15px; transform:
        scaleX(1.06956);">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.</span></p>
    <p>----<br>
    </p>
    <p>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.</p>
    <p>Gareth aka. Kit<br>
      <span style="left: 120px; top: 435px; font-size: 15px; transform:
        scaleX(1.06956);"></span><span style="left: 120px; top: 630px;
        font-size: 15px; transform: scaleX(1.05051);"></span></p>
    <div class="moz-cite-prefix">On 29/07/2019 23:47, J. Gareth Moreton
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:00ff7490-bbeb-f49c-2326-2645fae6d692@moreton-family.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <p>Hi everyone,</p>
      <p>So there's been an <a moz-do-not-send="true"
          href="https://bugs.freepascal.org/view.php?id=35905">issue
          raised</a> 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).</p>
      <p>According to <a moz-do-not-send="true"
          href="http://pascal-central.com/docs/iso7185.pdf">ISO7185</a>,
        page 55, section 6.8.3.5:<span style="left: 216.98px; top:
          309.033px; font-size: 16.4379px; font-family: serif;
          transform: scaleX(1.23018);" class=""></span></p>
      <p>"<span style="left: 332.046px; top: 383.003px; font-size:
          16.4379px; font-family: serif; transform: scaleX(1.09036);"
          class="">On execution of the <span class="highlight">case</span>-statement
          the <span class="highlight">case</span>-index shall be
          evaluated</span><span style="left: 839.977px; top: 383.003px;
          font-size: 16.4379px; font-family: serif; transform:
          scaleX(1.19102);">. That </span><span style="left: 177.529px;
          top: 402.729px; font-size: 16.4379px; font-family: serif;
          transform: scaleX(1.10037);" class="">value shall then specify
          execution of the statement of the <span class="highlight">case</span>-list-element
          closest-containing the</span><span style="left: 177.529px;
          top: 422.454px; font-size: 16.4379px; font-family: serif;
          transform: scaleX(1.11029);" class=""><span class="highlight">case</span>-constant
          denoting that value</span><span style="left: 424.098px; top:
          422.454px; font-size: 16.4379px; font-family: serif;
          transform: scaleX(1.16049);" class="">. One of the <span
            class="highlight">case</span>-constants shall be equal to
          the value of the </span><span style="left: 177.529px; top:
          442.18px; font-size: 16.4379px; font-family: serif; transform:
          scaleX(1.09033);" class=""><span class="highlight">case</span>-index
          upon entry to the <span class="highlight">case</span>-statement</span><span
          style="left: 494.781px; top: 442.18px; font-size: 16.4379px;
          font-family: serif; transform: scaleX(1.08542);">; otherwise,
          it shall be an error."</span></p>
      <p>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 <a
          moz-do-not-send="true"
          href="https://bugs.freepascal.org/view.php?id=35859">well-known
          ISO Pascal code</a> 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).<br>
      </p>
      <p>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).</p>
      <p>Gareth aka. Kit<br>
        <span style="left: 494.781px; top: 442.18px; font-size:
          16.4379px; font-family: serif; transform: scaleX(1.08542);"></span></p>
      <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
        <table style="border-top: 1px solid #D3D4DE;">
          <tbody>
            <tr>
              <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient"
                  target="_blank" moz-do-not-send="true"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
                    alt="" style="width: 46px; height: 29px;"
                    moz-do-not-send="true" width="46" height="29"></a></td>
              <td style="width: 470px; padding-top: 12px; color:
                #41424e; font-size: 13px; font-family: Arial, Helvetica,
                sans-serif; line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient"
                  target="_blank" style="color: #4453ea;"
                  moz-do-not-send="true">www.avast.com</a> </td>
            </tr>
          </tbody>
        </table>
        <a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
          height="1" moz-do-not-send="true"> </a></div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
fpc-devel maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
    </blockquote>
  </body>
</html>