Recent

Author Topic: FPC feature request/suggestion  (Read 3630 times)

440bx

  • Hero Member
  • *****
  • Posts: 1202
Re: FPC feature request/suggestion
« Reply #30 on: April 06, 2019, 06:28:22 pm »
The compiler already knows if the variable is initialized and gives a hint. Do you want it to issue a warning for that with new syntax?
No. The problem is that there the compiler is emitting a hint for a non-initialized "var" that it really shouldn't be emitting.  Here are the cases:

1.  for a var, the compiler cannot make any assumptions as to whether the variable is initialized or not, any assumption in that regard is simply incorrect and should be fixed.  FPC is emitting a hint for an un-initialized variable.  It shouldn't be doing that since passing an uninitialized var is correct and very common. 

I also want to note that, this in no way changes any of the semantics of the "var" keyword, everything stays the same _except_ for the part of the compiler that decides when to emit or not emit a hint.   

That should be cleaned up because the hint is the result of an incorrect assumption or, being a bit "too helpful".  Changing error handling is not the same as changing the language. 

2. if there was an "inout" way of passing a variable then the compiler can emit a warning for passing an uninitialized variable because "in" tells the compiler that the variable should have been initialized (something the "var" keyword does not do) and emit a warning if the "inout" variable isn't written to in the function/procedure.

What I'm suggesting is, clean up/correct the part of the compiler that mistakenly believes that a "var" should be initialized, that's incorrect.  Everything about "var" stays the same.

Add the keyword "inout" so the compiler can emit, not a hint but, a warning because "inout" explicitly tells the compiler that the variable should have been initialized.  Given that knowledge, it can rightfully emit a warning.

The other thing it automatically cleans up is the currently incorrect behavior of the -gt switch.  That switch _assumes_ that an "out" parameter has not been initialized, which is incorrect but, that assumption would be  correct if the compiler had a way for the programmer to declare that the variable should have been initialized, because in that case, "out" should only be used when the variable is _not_ initialized since, if the variable should be initialized then the parameter should be "inout" not just "out".

It would make things clean and _precise_ which FPC is seriously lacking in its handling of parameters. 

A bit of calling convention and warning management is good. Obsessing about it a poison.
It really is a terrible thing to want things done correctly.  It's so much easier to have them all messed up.
« Last Edit: April 06, 2019, 06:31:09 pm by 440bx »
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 1412
Re: FPC feature request/suggestion
« Reply #31 on: April 06, 2019, 06:48:19 pm »
1.  for a var, the compiler cannot make any assumptions as to whether the variable is initialized or not, any assumption in that regard is simply incorrect and should be fixed.  FPC is emitting a hint for an un-initialized variable.  It shouldn't be doing that since passing an uninitialized var is correct and very common. 
I do not think so. In my opinion, if a variable is declared as "var", then the function can read its value, which means that it is incorrect to pass an uninitialized variable to the function. Another thing is that there are a lot of incorrectly declared functions that just migrated from the time when there was no "out" modifier. As I understand it, introducing "inout" does not solve this problem, so this argument I reject. Because if we enter "inout", in any case we will need to rewrite many functions to "inout" and replace the meaning of "var" with "out". In my opinion, it is more correct to rewrite many functions from "var" to "out" without changing the meaning of "var" and introducing new syntax.

440bx

  • Hero Member
  • *****
  • Posts: 1202
Re: FPC feature request/suggestion
« Reply #32 on: April 06, 2019, 07:29:11 pm »
I do not think so. In my opinion, if a variable is declared as "var", then the function can read its value, which means that it is incorrect to pass an uninitialized variable to the function.
No, that is incorrect.  The passage from Niklaus Wirth's Pascal report makes it very clear.  No assumptions can be made nor are applicable to the initial state of a "var" because passing by reference is often done for performance reasons and/or to avoid potential stack overflows.

"var" is limited to inform the compiler that a variable should be passed by reference.  Nothing else.  That's its definition in the Pascal language.  There is nothing else associated with "var".

Another thing is that there are a lot of incorrectly declared functions that just migrated from the time when there was no "out" modifier. As I understand it, introducing "inout" does not solve this problem, so this argument I reject. Because if we enter "inout", in any case we will need to rewrite many functions to "inout" and replace the meaning of "var" with "out". In my opinion, it is more correct to rewrite many functions from "var" to "out" without changing the meaning of "var" and introducing new syntax.
I'm glad you brought that up.  If FPC was giving the _correct_ interpretation to "var" then it wouldn't be generating all those useless hints. 

The definitions are _correct_, what is incorrect is the assumption that a "var" parameter should already be initialized.  There are countless examples of "var" being used by a function/procedure to initialize parameters, they are not incorrect in any way, there is no reason to emit a hint against them.  It simply doesn't make any sense to emit a hint against them, their purpose is to initialize the parameter.

 A hint or even a warning would be appropriate if the parameter was declared as "inout" because in that case, the programmer is telling the compiler that the variable _should_ be initialized before passing it. 

Take this simple example:
Code: Pascal  [Select]
  1. GetClientRect(Wnd, ClientRect);
FPC, inappropriately complains that ClientRect should have been initialized.  If it handled "var" _correctly_ (which it does not) it wouldn't complain about it.

Now, take an API such as
Code: Pascal  [Select]
  1. SymGetLineNext(Process : THANDLE; inout Line : IMAGEHELP_LINE)
The Line parameter should have been previously initialized by a call to  SymGetLineFromAddr64 which uses a "var" for its Line parameter.

FPC is going to complain that Line has not been initialized when it finds the call to SymGetLineFromAddr64 and complain _again_ when the call to SymGetLineNext is made.   The reason for so much complaining from FPC is because it _incorrectly_ assumes that a variable should be initialized before being passed as a "var" parameter.

Get rid of that incorrect assumption and, in some cases, hundreds of utterly useless hints go away.   Not having to deal with all those useless hints would be rather nice as, would be having a compiler that follows some of the most basic standard Pascal behavior.

using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 1412
Re: FPC feature request/suggestion
« Reply #33 on: April 06, 2019, 07:59:03 pm »
"var" is limited to inform the compiler that a variable should be passed by reference.  Nothing else.  That's its definition in the Pascal language.  There is nothing else associated with "var".
We say the same about "value parameters". These are only "value parameters" and nothing more. "Value parameters are passed by value, while variable parameters are passed by reference", but otherwise they are the same. Parameters may contain garbage, but the compiler must be silent.

440bx

  • Hero Member
  • *****
  • Posts: 1202
Re: FPC feature request/suggestion
« Reply #34 on: April 06, 2019, 08:22:19 pm »
We say the same about "value parameters". These are only "value parameters" and nothing more. "Value parameters are passed by value, while variable parameters are passed by reference", but otherwise they are the same. Parameters may contain garbage, but the compiler must be silent.
No, that is logically incorrect.

A value parameter should be read otherwise there is no reason to pass it as a parameter.  Therefore, in that case, it is absolutely correct for the compiler to emit a warning that the value parameter has not been initialized.

In the case of a "var" parameter, the parameter may be read, it may be written or read and written, therefore the compiler cannot emit a warning for it not having been initialized.  One exception to that would be, if the compiler is smart enough to determine that the "var" parameter in a function/procedure is only read and remembers that fact when a variable is passed as a parameter to the function then, in that case and only in that case, a warning/hint would be appropriate.  Very few compilers out there are that smart.

That would be a nice and useful feature though.  Obviously, that would be way too much to ask for.


HTH.
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7508
Re: FPC feature request/suggestion
« Reply #35 on: April 06, 2019, 08:36:53 pm »
A bit of calling convention and warning management is good. Obsessing about it a poison.
It really is a terrible thing to want things done correctly.  It's so much easier to have them all messed up.

No, but *correctly* and *messed up* are horribly subjective. Moreover it is not just the "problem" (and that is already a too big word), but also your "solution", yet another incompatible extension.

Calling semantics are fixed by var, for warnings there shouldn't be any new syntax. If your API/units work with "initialized var", add a modeswitch that signals that.

440bx

  • Hero Member
  • *****
  • Posts: 1202
Re: FPC feature request/suggestion
« Reply #36 on: April 06, 2019, 08:44:53 pm »
No, but *correctly* and *messed up* are horribly subjective.
What a horrible thing to say, for a mathematician they aren't.

One thing is clear, that feature will not make it into FPC.  Logical consistency and correctness are obviously not priorities and, following standards is done when convenient.    Standards are just "ideas" anyway.
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 1412
Re: FPC feature request/suggestion
« Reply #37 on: April 06, 2019, 10:11:30 pm »
A value parameter should be read otherwise there is no reason to pass it as a parameter. 
A var parameter should be read otherwise there is no reason to pass it as var not out.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7508
Re: FPC feature request/suggestion
« Reply #38 on: April 06, 2019, 10:18:31 pm »
No, but *correctly* and *messed up* are horribly subjective.
What a horrible thing to say, for a mathematician they aren't.
[/quote]

Subjective should be easy to understand for mathematicians, as it is all about a different set of matrix of weights to weight the various arguments.

Quote
One thing is clear, that feature will not make it into FPC.  Logical consistency and correctness are obviously not priorities and, following standards is done when convenient.    Standards are just "ideas" anyway.

I can't make head or tails of this text. Which Standards? Whose Logic?

Both your argument as mine are logical. You just chose to focus solely on SSA warnings, I focus solely on defining a binary interface, and handle other aspects (like said meta data for warning generation) using directives, if needed (which I also have doubts about)

Akira1364

  • Hero Member
  • *****
  • Posts: 539
Re: FPC feature request/suggestion
« Reply #39 on: April 07, 2019, 12:47:44 am »
I don't have much to say here other than, there was definitely a time when FPC did not spit out hundreds and hundreds and hundreds of completely useless "uninitialized variable" warnings, for things as trivial as SetLength.

When exactly was this added, and who exactly was advocating for it? I've never seen a single person actually say they're happy that SetLength now warns about things that are blatantly already correct. Where are the people that actually wanted this to be a thing, and why did they want it?

If you ask me it's just a whole lot of clear false positives that detract from being able to pay attention to actual problems (and make the compiler seem amateurish, even though it isn't.)
« Last Edit: April 07, 2019, 12:51:58 am by Akira1364 »

440bx

  • Hero Member
  • *****
  • Posts: 1202
Re: FPC feature request/suggestion
« Reply #40 on: April 07, 2019, 01:26:23 am »
A var parameter should be read otherwise there is no reason to pass it as var not out.
Not true.  A var parameter isn't meant to state that a parameter will be read or written, only that it is passed by reference.

You're making the same mistake the FPC developers are making, associating "var" with usage it is not associated with.


« Last Edit: April 07, 2019, 02:29:55 am by 440bx »
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 1412
Re: FPC feature request/suggestion
« Reply #41 on: April 07, 2019, 09:47:07 am »
Not true.  A var parameter isn't meant to state that a parameter will be read or written, only that it is passed by reference.
Binary logic. It will either be read, then there is no point "inout", or it will not, then you need to use "out". And how the parameter is passed - by reference passed or by value is no longer important.

Peter H

  • Jr. Member
  • **
  • Posts: 57
Re: FPC feature request/suggestion
« Reply #42 on: April 07, 2019, 10:27:00 am »
I think a more general solution to this problem would be a dummy initialization:

Pascal should have a specialized intrinsic variable eg "void" that is assignement compatible to anything and that represents nothing.

a := void; //This doesnt generate code, because void doesnt exist, it is a dummy
someproc(a);

For now, the problem could be solved by:

if false then a := a; //The compiler should optimize this away.
someproc(a);
 8)

This program gives only warning about unreachable code.
Even at Optimization level zero there is no code generated for the initialization.
 ;D
Code: Pascal  [Select]
  1. program Project1;
  2. var i:integer;
  3. const j=0;
  4.  
  5.  
  6. procedure someproc(var i:integer);
  7. begin
  8.  i :=i;
  9. end;
  10.  
  11. begin
  12.   if false then i :=j;
  13.   someproc(i);
  14.   readln;
  15. end.
  16.  
  17.  

Variables must ALWAYS be initialized.
At least with a dummy initialization.  8-)

Another way would be RAII.

Variables should not be declared before they can be initialized.
Declaration and initialization should be in the same statement.
So if, as an exception to the rule, a variable is declared and not initialized then it is clear that the next step will be initialization.
This approach requires inline variable declaration, O:-)
« Last Edit: April 07, 2019, 12:04:43 pm by Peter H »

kupferstecher

  • Sr. Member
  • ****
  • Posts: 307
Re: FPC feature request/suggestion
« Reply #43 on: April 07, 2019, 01:14:27 pm »
I think a more general solution to this problem would be a dummy initialization:

Pascal should have a specialized intrinsic variable eg "void" that is assignement compatible to anything and that represents nothing.

a := void; //This doesnt generate code, because void doesnt exist, it is a dummy
What is it good for? (Absolutely nothing...)
You want to tell the compiler that you initialized the variable, although you didn't? What should the compiler do with this information? Remove his hint/warning? So you tell by that quer syntax you know what you are doing. Half year later you modify the code and actually use the uninitialized value. The compiler doesn't warn you, because in one moment you thought you have to trick the compiler. With a therefore created syntax feature...

440bx

  • Hero Member
  • *****
  • Posts: 1202
Re: FPC feature request/suggestion
« Reply #44 on: April 07, 2019, 01:34:35 pm »
Binary logic. It will either be read, then there is no point "inout", or it will not, then you need to use "out". And how the parameter is passed - by reference passed or by value is no longer important.
Serge, the point is that whether or not the language supports "out", that doesn't change the definition of "var".  That's the mistake, implicitly (or explicitly) changing the definition of a language construct because of the existence of another.  That is conceptually incorrect.

For instance, the existence of Int64 doesn't change the definition of Int32. They are completely independent definitions.  Nothing is associated with one because of the existence of the other.

"var" is a language construct used by the programmer to tell the compiler that a variable should be passed by reference.  No more, no less regardless of the existence of any other construct such as "out" and/or "constref".

The large number of useless hints FPC emits is one of the side effects of incorrectly associating behavior that is not applicable to "var".

There is absolutely nothing wrong nor incorrect with:
Code: Pascal  [Select]
  1. function GetClientRect(Wnd: HWND; var ClientRect : TRECT) : BOOL; etc

That's perfectly valid (ignore the etc, of course.) The incorrect association that "var" should be initialized results in "hints" that are meaningless and useless. 

That said, it would be better if that function was defined as
Code: Pascal  [Select]
  1. function GetClientRect(Wnd: HWND; out ClientRect : TRECT) : BOOL; etc
because that way, the compiler is given additional information which let's it know the function will change the parameter.  In addition to that, when the little codetools window pops up, the programmer gets that information which can often be useful.

When things are done correctly they usually work very nicely.  When  things are not correct, there are often undesirable side effects and in the case of the incorrect "var" association, that side effects is a torrent of worthless hints (among others.)

Honestly, all those useless hints are a real PITA.  Take a small unit of about 6000 lines that uses the API to get its work done and, the useful hints are drowned in a morass of useless hints.  It really makes using the compiler's messages a burden.   

That incorrect "var" association quickly becomes a real time waster.

HTH.




« Last Edit: April 07, 2019, 01:48:17 pm by 440bx »
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.