<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Ah yes, I see now - I've found the relevant line in ISO7185,
      section 6.8.3.5:</p>
    <p>"<span style="left: 430px; top: 428.333px; font-size: 16.6667px;
        font-family: serif; transform: scaleX(1.16);" class="">One of
        the <span class="highlight">case</span>-constants shall be
        equal to the value of the</span><span style="left: 180px; top:
        448.333px; font-size: 16.6667px; font-family: serif; transform:
        scaleX(1.09);" class=""><span class="highlight"> case</span>-index
        upon entry to the <span class="highlight">case</span>-statement</span><span
        style="left: 501.667px; top: 448.333px; font-size: 16.6667px;
        font-family: serif; transform: scaleX(1.0848);">; otherwise, it
        shall be an error."</span></p>
    <p><span style="left: 501.667px; top: 448.333px; font-size:
        16.6667px; transform: scaleX(1.0848);">Strict, but I guess that
        was what Pascal was built upon, and a good way to ensure the
        code is well-behaved.  Besides, I think my label count
        refactoring that Martok mentioned is quite good at redirecting
        labels to the endpoint if a branch is empty.  I can't say I
        fully agree with it being a warning or an error, but I can't
        argue with an ISO!  I guess I should be grateful that it's only
        a warning and not a straight-up compiler or run-time error.  I
        would still ponder about making it a note under FPC and ObjFPC,
        one level below a warning.<br>
      </span></p>
    <p><span style="left: 501.667px; top: 448.333px; font-size:
        16.6667px; transform: scaleX(1.0848);">Gareth aka. Kit</span></p>
    <p><span style="left: 501.667px; top: 448.333px; font-size:
        16.6667px; font-family: serif; transform: scaleX(1.0848);"><br>
      </span></p>
    <div class="moz-cite-prefix">On 18/05/2019 13:10, J. Gareth Moreton
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:72d4e198-be84-52c6-b9f0-bea4780c3e3c@moreton-family.com">Aah
      okay.  Thanks Martok and Jonas.  Adding internal errors is
      definitely a good haul then.  I do think a warning is a bit harsh
      though over a hint or a note, but if that is what you desire for
      the compiler (since it does reduce errors), then I'll accept it. I
      just missed the part where it only does it for small types.
      <br>
      <br>
      Gareth aka. Kit
      <br>
      <br>
      <br>
      On 18/05/2019 13:03, Jonas Maebe wrote:
      <br>
      <blockquote type="cite">On 18/05/2019 13:30, J. Gareth Moreton
        wrote:
        <br>
        <br>
        <blockquote type="cite">So it looks like this new warning has
          appeared as part of the data flow analysis of -O4.
          <br>
        </blockquote>
        <br>
        The case-completeness warning is not related to any optimization
        level, nor to the data flow analysis mentioned in the other
        thread.
        <br>
        <br>
        <blockquote type="cite">  The thing is, I personally have a
          problem with this being a warning, because there's nothing
          inherently wrong with not covering every case branch or
          omitting an else block (especially if one isn't needed). 
          Adding "else ;" everywhere seems to just cause bloat.
          <br>
        </blockquote>
        <br>
        The question is whether or not an else block is needed or not
        (or perhaps even superfluous). When I adapted the compiler code
        to compile warning-free with this new option, about 2/3 of the
        cases got an empty else-block and 1/3 got either an
        internalerror or extra case blocks to handle options that were
        not handled previously, but that should have been handled. I
        don't think that's a bad haul. There were also a number of
        case-statements that handled all possible options and yet still
        contained an else block (so the else-block got removed).
        <br>
        <br>
        However, it is absolutely true that this is not an issue in all
        cases. If you do not wish to see such warnings at all, you can
        always suppress them using -vm6060 (warning numbers can be
        discovered with the -vq command line options).
        <br>
        <br>
        For information on the background of this warning, see
        <a class="moz-txt-link-freetext" href="http://lists.freepascal.org/pipermail/fpc-devel/2019-January/039972.html">http://lists.freepascal.org/pipermail/fpc-devel/2019-January/039972.html</a>
        <br>
        <br>
        <blockquote type="cite">Still, code style aside, can I suggest
          the warning be downgraded into a hint? Warnings should
          indicate the possibility of unstable code due to uninitialised
          values, for example, and DFA should be able to detect that
          anyway as a separate warning (e.g. if a case block doesn't
          initialise an output value in all of its branches).
          <br>
        </blockquote>
        <br>
        This warning can detect errors that cannot be found by DFA,
        because they may not be related to initialising a variable (but
        e.g. to modifying an already initialised variable, or to
        outputting something).
        <br>
        <br>
        <br>
        Jonas
        <br>
        _______________________________________________
        <br>
        fpc-devel maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
        <br>
        <a class="moz-txt-link-freetext" href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      ---
      <br>
      This email has been checked for viruses by Avast antivirus
      software.
      <br>
      <a class="moz-txt-link-freetext" href="https://www.avast.com/antivirus">https://www.avast.com/antivirus</a>
      <br>
      <br>
      _______________________________________________
      <br>
      fpc-devel maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
      <br>
      <br>
      <br>
    </blockquote>
  <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <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"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></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;">www.avast.com</a>
                </td>
        </tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>