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

J. Gareth Moreton gareth at moreton-family.com
Sun May 19 13:18:20 CEST 2019


I'm aware of the term "lazy programmer", and to say I suffer from lazy 
programmer syndrome was still insulting because I pride myself on 
checking edge cases and making sure my code was thorough and robust (and 
if I overlook something in particular, I'll gladly have it pointed out 
so it can be fixed).  Up until now, there was nothing to say that 
omitting an *else* branch in a *case* block was lazy programming - for 
all I knew, it made sense because it clearly implied that you wanted 
nothing special to happen if none of the branches match - but to have 
the rules changed and the accusation applied retroactively was a grave 
insult.  Also, I don't drink, smoke or do drugs, and I absolutely abhor 
swearing, but you don't need to hear my life story.  Still, I apologise 
for my overreaction.

Back on point, I understand the people have spoken on this being a 
warning, but I can see this causing a rift among the development 
community when this warning suddenly gets thrown up on all their 
projects.  I can see the benefit though, especially with the smaller 
enumerations.  It just personally seemed that a warning was too harsh, 
and as Ryan Joseph pointed out, where is the line drawn? When is it 
acceptable to omit something?  For something like not initialising all 
of the fields in an object constructor, I will happily have a warning 
thrown at me because it counts as an uninitialised value, so long as 
it's not a false positive (since some fields may get set in a different 
method that's called by the constructor).  However, should not including 
an *else *branch in an *if* statement throw a warning - one can rightly 
argue that that's stupid, but isn't the principle the same as the *case 
*block?

I'm all for Pascal's design in forcing better programming standards, 
even little things like the assignment and equality operators are 
designed in such a way to prevent mistakes or subtle backdoors like that 
infamous one that someone tried to slip into the Linux kernel back in 
2003 
(https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/). 
Also a reason why I am vehemently against adding inline *var* 
declarations like what was done in the most recent rendition of Delphi, 
besides it violating the block design of Pascal.

Regarding the C-style assignment operators, some of the packages that 
come with the compiler use them, and trying to build everything without 
the -Sc flag will result in errors.  Outside of that, the biggest one 
that stands out is LazUTF8.pas for Lazarus - for example: Result += (nx 
* ONEMASK) >> ((sizeof(PtrInt) - 1) * 8); - that should probably be 
changed to something a little more Pascal-like, if Inc(Result, (nx * 
ONEMASK) *shr* ((sizeof(PtrInt) - 1) * 8)); is acceptable.

Gareth aka. Kit



---
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/20190519/d358d3dc/attachment.html>


More information about the fpc-devel mailing list