Using uninitialized object works on Win32, throws AV on Win64

[Dalija Prasnikar 1338]

5 minutes ago, Kryvich said:

The compiler should generate absolutely the same code for var and out parameters, both for the calling and for the called subroutines. The only difference will be in the warnings it issues:

Warning                                            var parameter    out parameter   Where to show
1. W1036 Variable might not have been initialized  yes              no              Calling routine
2. The parameter must be initialized before use    no               yes             Called routine
3. Return value of parameter might be undefined    no               yes             Called routine

Warnings 2. and 3. should work in the same way as for the Return value of a function (W1035 Return value of function might be undefined). That is, all the necessary checks (W1035, W1036) are already in the compiler, Embarcadero only has to apply them to the parameters where necessary.

I am usually all for warnings as they can help you detecting bad code and preventing bad code prevents bugs. But if there is a price to pay, if the warning makes too much noise, then such warning does more harm than good. Crappifying the code and losing the performance, just to catch few places where you turned off your brain before writing the code, is not an option for me. There are other tools that can catch such issues, compiler doesn't have to do everything.

 

Having the same warning for all implies that we wouldn't have the ability to disable var parameter warning without impacting all other places. If var parameter warning would be a separate one, that would be acceptable..

[Kryvich 163]

2 minutes ago, Attila Kovacs said:

as I mentioned before, to avoid the hints you have to act so you could make it an error instead of a hint

or are you the guy who having 2 kilometer of hints after a build?

I try to never allow hints or warnings in the release code.

 

Right now I am adapting the latest version of the PAS2JS transpiler for Delphi. I see dozens of warnings that Delphi shows. Most of them are false positive, such as an undefined function return value (W1035) after an exception is generated (RaiseInternalError(...);). But some potentially problematic places went unnoticed by the PAS2JS developers. Also, a lot of warnings are generated due to the different internal representation of strings in Free Pascal (UTF8) and Delphi (Unicodestring). I carefully study all warnings and correct the code.

[Lars Fosdal 1730]

I don't mind the compiler throwing hints and warnings - as I always fix them as they appear.

I even set some warnings to be errors - since they most likely are severe enough to dictate a no-tolerance policy.

 

[Attila Kovacs 617]

15 minutes ago, Lars Fosdal said:

I even set some warnings to be errors

wow, didn't know that function, have to check!!

[Uwe Raabe 1877]

38 minutes ago, Dalija Prasnikar said:

There are other tools that can catch such issues, compiler doesn't have to do everything.

Agree. I prefer Pascal Analyzer to get notified about problems like the one this thread is all about. In contrast to the compiler, eliminating all warnings from Pascal Analyzer is not the goal. If I don't want to get notified the next time I can suppress it with a simple comment.

[Kryvich 163]

44 minutes ago, Uwe Raabe said:

Agree. I prefer Pascal Analyzer to get notified about problems like the one this thread is all about. In contrast to the compiler, eliminating all warnings from Pascal Analyzer is not the goal. If I don't want to get notified the next time I can suppress it with a simple comment.

I tried the TestInitialization project with Pascal Analyzer Lite, but it doesn't see a problem with using an uninitialized var parameter either. Perhaps the full paid version will determine this issue.

 

Edited January 31, 2022 by Kryvich

[David Heffernan 2290]

1 hour ago, Uwe Raabe said:

There are probably plenty of methods, built-in or from 3d party libraries, that offer only var parameters where out would be the better choice, but we are not able to change the signature.

Sure. But there are plenty of methods where you can make changes. Just because something doesn't solve all problems, doesn't mean that solving some problems isn't possible or useful.

 

But for sure in an ideal world we would have in, out and in/out parameters implemented with the same functionality as C#. I'd be very happy to have a breaking change to the compiler and migrate my code to such a language.

Edited January 31, 2022 by David Heffernan

[Uwe Raabe 1877]

16 minutes ago, Kryvich said:

I tried the TestInitialization project with Pascal Analyzer Lite, but it doesn't see a problem with using an uninitialized var parameter either. Perhaps the full paid version will determine this issue.

Yes, it reports that warning:

Quote

Local variables that are referenced before they are set (1, was unknown):
----------------------------------------------------------------------------

a : Integer                    Var, Local              TestInitialization\Test (13)
a                              Read+Set                TestInitialization (15)
a                              Read+Set                TestInitialization (16)
 

 

[Fr0sT.Brutal 897]

2 hours ago, Kryvich said:

Most of them are false positive, such as an undefined function return value (W1035) after an exception is generated (RaiseInternalError(...);).

Bad practice that Delphi RTL started itself. If usual clause is not applicable for some reason, why not write "raise CreateInternalError(...)"? Mystery for me

[Kryvich 163]

6 minutes ago, Fr0sT.Brutal said:

Bad practice that Delphi RTL started itself. If usual clause is not applicable for some reason, why not write "raise CreateInternalError(...)"? Mystery for me

Definitely it would look better and not generate tons of compiler warnings in Delphi. They grab this practice from FPC. See pasresolver.pp, there are procedures like RaiseMsg, RaiseNotYetImplemented, RaiseInternalError, RaiseInvalidScopeForElement. All of them can be replaced with custom exceptions.

[dummzeuch 1387]

4 hours ago, Kryvich said:

Definitely it would look better and not generate tons of compiler warnings in Delphi. They grab this practice from FPC. See pasresolver.pp, there are procedures like RaiseMsg, RaiseNotYetImplemented, RaiseInternalError, RaiseInvalidScopeForElement. All of them can be replaced with custom exceptions.

I doubt that this was taken up from FPC by the Delphi team. Do you have any evidence for this? My guess would be the other way round.

Edited January 31, 2022 by dummzeuch

[Kryvich 163]

29 minutes ago, dummzeuch said:

I doubt that this was taken up from FPC by the Delphi team. Do you have any evidence for this? My guess would be the other way round.

I wrote about PAS2JS developers. PAS2JS is a subproject of FPC, written mostly in the same style.