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

[J. Gareth Moreton]

Yes, I'm jumpy, especially as you always like to open your responses 
with a direct insult of some kind - yes, I checked.  You want to kill me 
or ban me from the mailing list, go right ahead. I'm sure Free Pascal 
will survive without me.


We will agree to disagree on that one.  I see a warning as an actual 
warning that the code is very likely to cause unpredictable results or 
is an obvious oversight, like an uninitialised variable or a conditional 
block that is impossible to branch into (in this case, an 'unreachable 
else' for the case block would be a warning).  A hint is an optimisation 
tip that might also indicate laziness, like a variable declaration 
that's never used because you removed some old code or neglected to use 
it, while a note is a bit more serious than a hint but not as severe as 
a warning.


I'm not the only one who wasn't aware of the ISO standard - evidently 
Borland never followed through with it and most other Pascal 
programmers.  Until recently, even the compiler was full of omitted 
blank else blocks.  I would have thought that the lack of an else 
section on a case block is fairly indictive of one not being necessary, 
and any special values that need to be handled should contain their own 
branches.


Now don't get me wrong, I do agree that a notification is useful - as 
Jonas said, at least 1/3 of the messages pointed to case blocks that 
benefitted from having internal errors added, since an explicit branch 
should always be taken - an example of a manual one that Pierre and I 
implemented is the one that appears in TEntryFile.GetAInt, because 
SizeOf(AInt) should always return 1, 2, 4 or 8.  But a lot of the time, 
one may only want to check a select number of values for special 
operations, but which are numerous to the point that individal if 
statements are inefficient - for example, 
TCpuAsmOptimizer.PeepHoleOptPass1Cpu under x86_64 - having an empty else 
block, while certainly safer, comes off as superfluous since, in that 
case, it doesn't give any extra information.  Granted, if the standard 
of an obligatory 'else' was adhered to from the very beginning, we 
wouldn't be in this situation, but like the problem of 'inline' 
appearing only in the implementation section of subroutines, there is so 
much code out there now that it will be an endless battle to change it 
all to adhere to the standard and not break something.


I just feel that in this case, it should be a note, not a warning, 
unless you're compiling under a dialect of Pascal (e.g. Extended) that 
is stricter in its interpretation of the whitesheet and demands an error 
be returned.


Gareth aka. Kit

P.S. And while I agree that one should not merely look towards C and C++ 
for inspiration (I see the practice of lowercasing everything and not 
having a space between operators and operands as 'colonisation', for 
lack of a better term), it seems that we are a little inconsistent when 
it comes to that, given that Free Pascal supports the C-style assignment 
operators now.



On 19/05/2019 02:42, Ralf Quint wrote:

On 5/18/2019 3:42 PM, J. Gareth Moreton wrote:


Lazy... you've got a bloody cheek.  Well I guess there's no point in 
me contributing anything more if that's how you honestly view me.  I 
wasn't aware of the ISO that dictated that a case block shouldn't 
just fall through until today, and C/C++ and Basic never threw 
similar errors or warnings, so I didn't know this was a thing.



Wow, a bit jumpy, aren't we?

As we are talking here about a Pascal compiler, it doesn't matter what 
C/C++ or BASIC do. And even in other programming languages, properly 
acting upon unexpected conditions is good programming practice. And 
commonly people programming in Pascal are ones that try to adhere to 
good programming practices, not just ignore them out of whatever 
convenience they might perceive.


A warning from the compiler is hence an appropriate response, telling 
the programmer to check the source and make a decision, even if it is 
adding an empty else clause to the offending case statement. 
Everything else is just "lazy programming", like it or not...


Ralf



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Ryan Joseph]

> On May 18, 2019, at 7:42 PM, Ralf Quint  wrote:
> 
> A warning from the compiler is hence an appropriate response, telling the 
> programmer to check the source and make a decision, even if it is adding an 
> empty else clause to the offending case statement. Everything else is just 
> "lazy programming", like it or not...
> 
> Ralf

Then should all if statements have an else? Should constructors give warnings 
if you don’t initialize all fields? It’s a slippery slope.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Ralf Quint]

On 5/18/2019 3:42 PM, J. Gareth Moreton wrote:


Lazy... you've got a bloody cheek.  Well I guess there's no point in 
me contributing anything more if that's how you honestly view me.  I 
wasn't aware of the ISO that dictated that a case block shouldn't just 
fall through until today, and C/C++ and Basic never threw similar 
errors or warnings, so I didn't know this was a thing.



Wow, a bit jumpy, aren't we?

As we are talking here about a Pascal compiler, it doesn't matter what 
C/C++ or BASIC do. And even in other programming languages, properly 
acting upon unexpected conditions is good programming practice. And 
commonly people programming in Pascal are ones that try to adhere to 
good programming practices, not just ignore them out of whatever 
convenience they might perceive.


A warning from the compiler is hence an appropriate response, telling 
the programmer to check the source and make a decision, even if it is 
adding an empty else clause to the offending case statement. Everything 
else is just "lazy programming", like it or not...


Ralf



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Could the following be merged to 3.2.0 please (committed by Sven)

[Marco van de Voort]

Op 2019-05-18 om 19:10 schreef Martin:

See the list below. I wonder if they could be merged?


r42098


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[J. Gareth Moreton]

Lazy... you've got a bloody cheek.  Well I guess there's no point in me 
contributing anything more if that's how you honestly view me.  I wasn't 
aware of the ISO that dictated that a case block shouldn't just fall 
through until today, and C/C++ and Basic never threw similar errors or 
warnings, so I didn't know this was a thing.


Good day.


On 18/05/2019 22:56, Ralf Quint wrote:

On 5/18/2019 4:30 AM, J. Gareth Moreton wrote:

Hi everyone,

So it looks like this new warning has appeared as part of the data 
flow analysis of -O4.  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.


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). 


Sorry, but you seem to suffer from the "lazy programmer syndrome". A 
warning is correct, as a case of unhandled */case/* statement can 
indeed lead to unexpected side effects. While there could be cases 
where you might want to react with the /*case*/ statement to only 
certain conditions (and can safely assume that all other conditions 
don't do ill effects), there is also the case where an 
unknown/unexpected condition is passed and that can have dire 
consequences, and should be properly acted upon, by the /*else*/ 
clause within the case statement...


Ralf



 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
fpc-devel maillist  -  fpc-devel@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Ralf Quint]

On 5/18/2019 4:30 AM, J. Gareth Moreton wrote:

Hi everyone,

So it looks like this new warning has appeared as part of the data 
flow analysis of -O4.  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.


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). 


Sorry, but you seem to suffer from the "lazy programmer syndrome". A 
warning is correct, as a case of unhandled */case/* statement can indeed 
lead to unexpected side effects. While there could be cases where you 
might want to react with the /*case*/ statement to only certain 
conditions (and can safely assume that all other conditions don't do ill 
effects), there is also the case where an unknown/unexpected condition 
is passed and that can have dire consequences, and should be properly 
acted upon, by the /*else*/ clause within the case statement...


Ralf




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Could the following be merged to 3.2.0 please (committed by Sven)

[Sven Barth via fpc-devel]

Marco van de Voort  schrieb am Sa., 18. Mai
2019, 19:56:

>
> Op 2019-05-18 om 19:10 schreef Martin:
> > See the list below. I wonder if they could be merged?
>
> If Sven sees no problems ( just say the word), and I'll merge them.
>

No problems from my side :)

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures/anonymous functions update

[Ryan Joseph]

> On May 18, 2019, at 11:41 AM, Blaise Thorn  wrote:
> 
> Saturday, May 18, 2019 8:32 PM +03:00 from Ryan Joseph 
> :
>> After 2 months now I’ve not been able to get the required sources to help 
>> finish the closures branch.
>> The author Blaise did manage to contact me once but then went silent so I 
>> don’t know what happened.
> 
> Only yesterday, I have finished setting up https://hg.blaise.ru/ (which is 
> now a separate server), and issued certificates. So, it /has/ been moving 
> forward all this time, albeit slowly.

There you are! I thought you moved on. That’s good news but you can just send 
me anything you need in the mean time instead of setting up an entire server 
first. Mainly I just wanted to see the current state of it so I can know where 
to start or what’s left. Not sure if you did everything the compiler team asked 
yet or not.

Thanks for replying.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures/anonymous functions update

[Blaise Thorn]

Saturday, May 18, 2019 8:32 PM +03:00 from Ryan Joseph 
:
> After 2 months now I’ve not been able to get the required sources to help 
> finish the closures branch.
> The author Blaise did manage to contact me once but then went silent so I 
> don’t know what happened.

Only yesterday, I have finished setting up https://hg.blaise.ru/ (which is now 
a separate server), and issued certificates. So, it /has/ been moving forward 
all this time, albeit slowly.

-- 
βþ
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Could the following be merged to 3.2.0 please (committed by Sven)

[Marco van de Voort]

Op 2019-05-18 om 19:10 schreef Martin:

See the list below. I wonder if they could be merged?


If Sven sees no problems ( just say the word), and I'll merge them.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Closures/anonymous functions update

[Ryan Joseph]

After 2 months now I’ve not been able to get the required sources to help 
finish the closures branch so I guess it’s best to go to plan B and see if it’s 
feasible to finish at the last public repository I found. The author Blaise did 
manage to contact me once but then went silent so I don’t know what happened.

I’ve found a few bugs that need fixing but most of it seems to work as far as 
I’ve tested. Blaise claimed there were some "lifetime management issues” but I 
can’t find them yet (maybe this was an older version he was referring to). The 
only serious bug I can’t figure out yet is a runtime crash when declaring 
anonymous functions in class constructors.

Here’s what I managed to salvage so far with some requested changes made (see 
below).

https://github.com/genericptr/freepascal/tree/closures

Here’s the list of old comments from 2015-2016 which I was able to find using 
my detective skills and I corrected some of them. 

The only concerning thing is that Jonas had a request (reasonable however 
challenging) that the variable capturing process be unified with the existing 
code for nested procedures. I’m struggling to understand how this works however 
and I’m not certain if a) this is still important and b) if it’s even a good. 
The closures actually have a very minimal footprint in other parts of the 
compiler and is very non-invasive as it is. My feeling is that it’s not worth 
it to merge the two methods as it would complicate both but I’m really not 
sure. Anyways, if that’s required than this is the by far the biggest chunk of 
work left because it requires redoing a significant part of the design.

I wanted to make an alternate capture mode as an optimization for closures that 
don’t get passed outside of their scope but I wasn’t able to figure this out 
yet (using old-style objects instead of classes). It’s a waste to allocate a 
new class if not needed (this would hurt realtime graphics applications badly) 
so that should be tackled eventually. Maybe they can be made to inline or 
something, not sure how to handle it though.

What does the compiler team think about this? Can you guide me so I could 
finish what was started? Please update me on what needs to be done to get this 
moving along.

// https://fpc-devel.freepascal.narkive.com/ONaPiCka/closures-anonymous-methods
// http://lists.freepascal.org/pipermail/fpc-devel/2016-January/036479.html

{ 
  = Jonas:

  First of all, thanks for your work, and sorry for the late reaction.

  I was wondering whether you could rework the above functionality based  
  on the code in ncgnstld.pas/ncgnstmm.pas. That is code which is used  
  by the JVM and LLVM code generators to access nested variables. It  
  adds all variables that are used by nested routines to a record, and  
  then passes a pointer to this record as "parentfp" parameter (since  
  those platforms do not have a stack or frame pointer register that can  
  be passed on). This seems quite similar to what you're doing with  
  load_captured_sym() etc. Alternatively, maybe your code is better and  
  that code could be refactored to make use of your routines. I have not  
  yet studied your code in detail yet.

  One advantage would be that the existing code already handles this too  
  (for plain nested routines):

  = Sven:

  Sorry that it took me so long to answer. I have looked at your changes 
  shortly after you published them, but then I forgot... Mea culpa.

  First of thank you for the work you've done. I think I've said this in 
  the private mail I sent you already, but better I do it here as well. :)

  Now of course there are still quite some things aside from those that 
  you mentioned above. I'll just list them in no particular order:

  √ use our usual license header in pnameless.pas (see for example ogomf.pas)

  √ include the fpcdefs.inc in pnameless and don't use mode Delphi

  √ please don't use features (in this case C-style operators) that are 
  neither enabled by default in mode ObjFPC nor a enabled in fpcdefs.inc

  √ I'd prefer if you'd use the term "anonym" instead of "nameless" as 
  this way one not only can derive more easily that you mean anonymous 
  functions, but in addition to that the unit name would fit into the 8.3 
  scheme (this point includes both the unit name as well as the 
  oo_is_nameless and po_nameless flags)

  √ don't have defcmp depend on pnameless; instead move 
  are_compatible_interfaces() and are_compatible_headers() to defcmp (you 
  don't need to put everything and the kitchen sink into the pnameless unit)

  - analogous for load_contextual_self(); maybe even move that to a new 
  unit altogether as this doesn't really deal with nameless/anonym 
  functions, but more with the closure part of the concept (so either 
  nutils.pas or a new nclosure.pas as it's dealing more with nodes than 
  parsing)

  √ do *not* call internalerror if the user can easily trigger it; in that 
  case it would be the one in factor() 

[fpc-devel] Could the following be merged to 3.2.0 please (committed by Sven)

[Martin]

See the list below. I wonder if they could be merged?

Thanks for considering.


Revision: 42087
Date: 16 May 2019 22:56:18
Message: * fix for Mantis #35566 by applying patch by Martin Friebe: 
correctly dereference the 32-bit length value for Windows Widestrings


Revision: 42039
Date: 11 May 2019 17:38:59
Message:* addstringdef() now correctly declares the debug information 
for a Windows WideString, so use that instead of treating it merely like 
a PWideChar


Revision: 42038
Date: 11 May 2019 17:38:56
Message:* fix for Mantis #35386: use the correct size for the string's 
length (SizeInt for Ansi-/UnicodeString and DWord for WideString)


Revision: 42037
Date: 11 May 2019 17:38:51
Message:* fix for Mantis #35359: only WideString counts the size in 
Byte, UnicodeString uses the size in WideChars



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [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@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[J. Gareth Moreton]

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@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martok]

It's not DFA.

See my proposal thread from January and Jonas' implementation from this week:




> Warnings should indicate the possibility of unstable code due to 
> uninitialised values

As long as the core question remains unanswered, these are required exactly
because in cases (pun intended) where they exist, the compiler may do something
very different from what was intended, and even be wildly different between
platforms.

I would prefer literally any other solution (such as the two-line-patch my
Windows trunk builds have contained for two years now), but this is the one that
gets merged. Go figure.


-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Jonas Maebe]

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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[J. Gareth Moreton]

Hi everyone,

So it looks like this new warning has appeared as part of the data flow 
analysis of -O4.  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.


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).


Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc trunk fails to build (win32/64)

[Marco van de Voort]

Op 2019-05-18 om 12:31 schreef Martin Frb:


It's a known issue,  please pass ALLOW_WARNINGS=1  to make to avoid 
it for now.


OK, will do.

I reported it, because a month ago it was compiling fine (with the 
same settings)


A ticket is always a good thing as a reminder that it is not fixed. And 
it provides a place to document the workaround.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc trunk fails to build (win32/64)

[Martin Frb]

It's a known issue,  please pass ALLOW_WARNINGS=1  to make to avoid it 
for now.


OK, will do.

I reported it, because a month ago it was compiling fine (with the same 
settings)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc trunk fails to build (win32/64)

[J. Gareth Moreton]

On 18/05/2019 11:13, Marco van de Voort wrote:
n386flw.pas(142,21) Warning: Case statement does not handle all 
possible cases


What's this warning all about? There are far too many situations where 
you may not want to handle all possible cases and the implicit else 
block just goes to the first line after the case block - e.g. the 
peephole optimizer.  This really doesn't feel like a warning, more like 
a hint at best.


Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc trunk fails to build (win32/64)

[Marco van de Voort]

Op 2019-05-18 om 01:47 schreef Martin:

I reported one case already.
https://bugs.freepascal.org/view.php?id=35598

Compiling 42090 for win32 with the options
-gl -O4 -Or
fails with the warning/error: defutil.pas(1606,7) Warning: Function 
result variable does not seem to initialized


Just run into the next error. Compiling with -gl -gw -godwarfsets -O-1 
-dTEST_WIN32_SEH


c:/FPC/fpc_3.3.1/source/compiler/ppc1.exe -XX -CX -Ur -Xs -O2 -n -O2 
-Fui386 -Fusystems -Fuc:/FPC/fpc_3.3.1/source/rtl/units/i386-win32 
-Fii386 -FEi386/bin/i386-win32 -FUi386/units/i386-win32 -dRELEASE -gl 
-gw -godwarfsets -O-1 -dTEST_WIN32_SEH    -di386 -dGDB -dBROWSERLOG 
-Fux86 -Sew pp.pas
n386flw.pas(142,21) Warning: Case statement does not handle all 
possible cases
n386flw.pas(153,21) Warning: Case statement does not handle all 
possible cases

n386flw.pas(675) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted


And if you fix it, it will just pass on to the next one (in ngen* iirc)

It's a known issue,  please pass ALLOW_WARNINGS=1  to make to avoid it 
for now.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel