Ah yes, I see now - I've found the relevant line in ISO7185, section
6.8.3.5:
"One of the case-constants shall be equal to the value of thecase-index
upon entry to the case-statement; otherwise, it shall be an error."
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.
Gareth aka. Kit
On 18/05/2019 13:10, J. Gareth Moreton wrote:
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.
Gareth aka. Kit
On 18/05/2019 13:03, Jonas Maebe wrote:
On 18/05/2019 13:30, J. Gareth Moreton wrote:
So it looks like this new warning has appeared as part of the data
flow analysis of -O4.
The case-completeness warning is not related to any optimization
level, nor to the data flow analysis mentioned in the other thread.
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.
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).
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).
For information on the background of this warning, see
http://lists.freepascal.org/pipermail/fpc-devel/2019-January/039972.html
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).
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).
Jonas
_______________________________________________
fpc-devel maillist - [email protected]
http://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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
