[fpc-devel] "Case statement does not handle all possible cases" Warning

[J. Gareth Moreton]

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  -  fpc-devel at lists.freepascal.org
>> 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  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190518/fa13ed70/attachment.html>