Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2019-02

Re: fpc-devel Digest, Vol 178, Issue 38

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Franz Müller

Well one of the answer in the Cantu blog has this ( which I changed to lets say a "real world" relative big function ) :

var arr: array... function Fuckup: boolean; var I: Integer; begin
  <....> 20 lines of code  for var I := Low(arr) to High(arr) do if
arr[I]..... then break; <....> 20 lines of code  Result := (I <=
High(arr)); end; regards, -- Dimitrios Chr. Ioannidis

It's a nice example why scoped variables would be in fact better, because the value of i is undefined if the for loop is exited normally. So even the original code wouln't work as expected, you cannot rely on i>High(arr) in that case, it depends on the way the for loop is implemented. Using only the variable local to the loop would cause a compiler error, while using only the variable defined in the function body would not even cause a warning but leed to unwanted results.

On the other side, using a scoped variable while knowing that you will need the value of the value of the variable later is a kind of stupidity which will make this one a minor probem, compared to thers that such a programmer woud introduce into the code...

I don't know how inline variables are defined in Delphi, but forbidding to use names for inline variables which are already known at that place of the code, no matter where they have been defined, would eliminate this potential problem completely. (And if such a restriction does not exist in Delphi, it could be removed just for $mode delphi to keep compatibility, while the other compiler modes would ensure code safety in that respect.)

Reply by email

Martin Frb
to Franz Müller
Franz Müller wrote 6 lines
It's a nice example why scoped variables would be in fact better, because the value of i is undefined if the for loop is exited normally. So even the original code wouln't work as expected, you cannot rely on i>High(arr) in that case, it depends on the way the for loop is implemented. Using only the variable local to the loop would cause a compiler error, while using only the variable defined in the function body would not even cause a warning but leed to unwanted results.

That does not need inlined variables.

The compiler already has a warning about uninitialized vars. If not detected after a for loop, this should be improved (rather than adding some other workaround).

And there is a command line switch to tread warnings as errors. So that problem is perfectly solve-able.

Reply by email

Nikolai Zhubr
to Martin Frb

Hi,

21.02.2019 17:41, Martin Frb:

Show quoted text 16 lines
On 20/02/2019 19:31, Franz Müller wrote: > It's a nice example why scoped variables would be in fact better, > because the value of i is undefined if the for loop is exited > normally. So even the original code wouln't work as expected, you > cannot rely on i>High(arr) in that case, it depends on the way the for > loop is implemented. > Using only the variable local to the loop would cause a compiler error, while using only the variable defined in the function body would not even cause a warning but leed to unwanted results. That does not need inlined variables. The compiler already has a warning about uninitialized vars. If not detected after a for loop, this should be improved (rather than adding some other workaround). And there is a command line switch to tread warnings as errors. So that problem is perfectly solve-able.

Actually no. Inline declarations (where implemented) are not limited to a loop index and not even limited to a loop. If you have an option to declare some few variables locally to some code block (e.g. FOR, as well as IF, CASE, WHILE, etc), in case you know for sure from their meaning that their values just make no sense outside of this very block, you would know they do not leak out accidentally. This is certainly not the same as detecting uninitialized variables. A variable might be technically initialized, but at the same time its value might make no sense outside of some scope (for the reasons of your business logic or whatever else considerations).

Thank you,

Regards,
Nikolai

Show quoted text 6 lines
_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Martin Frb
to Nikolai Zhubr
Nikolai Zhubr wrote 12 lines
Actually no. Inline declarations (where implemented) are not limited to a loop index and not even limited to a loop. If you have an option to declare some few variables locally to some code block (e.g. FOR, as well as IF, CASE, WHILE, etc), in case you know for sure from their meaning that their values just make no sense outside of this very block, you would know they do not leak out accidentally. This is certainly not the same as detecting uninitialized variables. A variable might be technically initialized, but at the same time its value might make no sense outside of some scope (for the reasons of your business logic or whatever else considerations).

Search the forum and mail history. The discussion has been add several times. And there are plenty of more examples, why it is not good. No point in repeating them. Especially not, since the decision has afaik already been made long ago.

Reply by email