Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Sat, July 1, 2017 16:45, Martok wrote: Hi, > The attitude displayed over on #32079 is, quite frankly, terrifying. > Apparently a language which from the beginning has intrinsics for reading > and writing files must never be used for doing so, or wild things may > happen /and that's okay/. >

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

The attitude displayed over on #32079 is, quite frankly, terrifying. Apparently a language which from the beginning has intrinsics for reading and writing files must never be used for doing so, or wild things may happen /and that's okay/. Implying that input should already be sanitized on a bug

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

In our previous episode, Martin said: > > Interestingly, I just ran into "bad" code generation with exactly the > > properties > > discussed in this thread. > > Because every declared element is covered, the generated code for it ends up > > being a computed goto: > > and most importantly, not

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 28/06/2017 20:03, Martok wrote: Interestingly, I just ran into "bad" code generation with exactly the properties discussed in this thread. Because every declared element is covered, the generated code for it ends up being a computed goto: and most importantly, not into any else statement.

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

Interestingly, I just ran into "bad" code generation with exactly the properties discussed in this thread. Take a function like this: function SignatureSubpacketTypeToStr(const X: TSignatureSubpacketType): String; begin case X of sstReserved00 : Result:= 'Reserved00'; sstReserved01

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Thu, Jun 8, 2017 at 3:22 AM, Denis Kozlov wrote: > I can't control what values other users/developers may supply, nor I > restrict the use of different compiler versions and build flags. Compiler flags have nothing to do with the fundamental issue here. If other developers

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 07/06/2017 15:18, Juha Manninen wrote: The compiler trusts that data in an enum variable is legal, within the range. It should trust the same way when doing DFA. It is logical and consistent. I understand your reasons now and agree that DFA should cover only logical (according to the

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Wed, Jun 7, 2017 at 2:04 AM, Denis Kozlov wrote: > You suggest that only Convert3 function should raise "uninitialized result" > warning, while Convert1 and Convert2 should not. I find this less useful, > and, again, you can rightfully disagree, but it won't change the fact

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 07/06/2017 00:04, Denis Kozlov wrote: Consider the code fragment below. Currently, FCP 3.0.2 with -O3 shows "uninitialized result" warning for Convert2 and Convert3 functions, but not for Convert1. I find this perfect as is, and, of course, you can rightfully disagree. You suggest that

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

Juha, Just to get this straight, I am talking about DFA and your proposal to remove "uninitialized result" warning when all declared values of a set have been enumerated in a case statement. I don't have any issues with range check errors, they were brought up and became part of

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

Am 05.06.2017 um 20:49 schrieb Jonas Maebe: > On 05/06/17 20:37, Denis Kozlov wrote: >> >> >> On 05/06/2017 18:59, Jonas Maebe wrote: >>> That is why I said "If range checking is off there or disabled via an >>> explicit type cast, then >>> the result is undefined by definition." You use an

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Mon, Jun 5, 2017 at 9:37 PM, Denis Kozlov wrote: > I just wanted to highlight that these cases as legal and I presume not > uncommon, particularly if values are deserialized and typecasted. No they are not legal. Why you write this nonsense? Values outside the range dictated

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 05/06/17 20:37, Denis Kozlov wrote: On 05/06/2017 18:59, Jonas Maebe wrote: That is why I said "If range checking is off there or disabled via an explicit type cast, then the result is undefined by definition." You use an explicit typecast above. > > I just wanted to highlight that these

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 05.06.2017 20:37, Denis Kozlov wrote: > > I just wanted to highlight that these cases as legal and I presume not > uncommon, particularly if values are deserialized and typecasted. They are legal in the sense that they result in undefined behavior and in that case the compiler is free to act

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

I just wanted to highlight that these cases as legal and I presume not uncommon, particularly if values are deserialized and typecasted. It seems that there is no way for compiler to know if the result has indeed being initialized by reason of enumeration of valid values, because one has

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Monday, June 5, 2017, Denis Kozlov wrote: > I have just created a new GUI application, enabled range checking "-Cr" > and executed the following: > ShowMessage(IntToStr(Form1.BorderSpacing.GetSpace(TAnchorKind(-1; > The displayed value is a semi-random integer. No

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 05/06/17 19:39, Denis Kozlov wrote: I have just created a new GUI application, enabled range checking "-Cr" and executed the following: ShowMessage(IntToStr(Form1.BorderSpacing.GetSpace(TAnchorKind(-1; The displayed value is a semi-random integer. No compiler errors or run-time

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

I have just created a new GUI application, enabled range checking "-Cr" and executed the following: ShowMessage(IntToStr(Form1.BorderSpacing.GetSpace(TAnchorKind(-1; The displayed value is a semi-random integer. No compiler errors or run-time errors. P.S. Same behaviour for Lazarus

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

For some reason my reply went only to Denis first. Another try here... On Mon, Jun 5, 2017 at 7:46 PM, Denis Kozlov wrote: > Result is undefined if caller passes an out of range value. > An example: TControlBorderSpacing.GetSpace(TAnchorKind(-1)); > Result is indeed not

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 05/06/17 18:46, Denis Kozlov wrote: Result is undefined if caller passes an out of range value. That would be an error at the time this out-of-range value would be converted to TAnchorKind. If range checking is off there or disabled via an explicit type cast, then the result is undefined

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

Result is undefined if caller passes an out of range value. An example: TControlBorderSpacing.GetSpace(TAnchorKind(-1)); Result is indeed not initialized, so silencing this message may be harmful. Denis On 05/06/2017 15:22, Juha Manninen wrote: Wiki tells about problems the dfa encounters: