Variable initialization

[BubikolRamios]

EDIT: Possible that extended shows 0 at breakpoint even if there is something else than 0 ?

Just lost hours, at not initialized variables.
Within for next, breakpoint, all looked OK, sumSin... 0 at start, without initialization, at end calculations wrong
Copied whole thing out, no initialization, complained at run time variables not initialized.
Added initialization and runs OK , calculates OK.

Code: Pascal  [Select][+][-]

1. var
2.   sumSin,sumCos: Extended;
3. begin
4.   sumSin := 0;
5.   sumCos := 0;
6.  
7.  
8.   for i := 0 to  length(anglesArrDeg)-1 do
9.   begin
10.     sumSin := sumSin + sin(DegToRad(anglesArrDeg[i]));
11.     sumCos := sumCos + cos(DegToRad(anglesArrDeg[i]));
12.  end;
13.  

[n7800]

Local variables must always be initialized. Sometimes they accidentally end up zero, but this is just a coincidence.

Only global variables and class fields are guaranteed to be zero.

Documentation: https://www.freepascal.org/docs-html/current/ref/refse24.html

[Martin_fr]

EDIT: Possible that extended shows 0 at breakpoint even if there is something else than 0 ?

Depends on a lot of factors.... Albeit, I would expect the correct value or an error, but that said there could be (have been) a bug...

First of all: Is your sig up to date:

lazarus 3.2-fpc-3.2.2-win32/win64

That is old, really old.

If it is that, and if you use a 64bit IDE to cross debug a 32bit project, and you use FpDebug, then it should probably have shown an error, but who knows, could have been buggy to show zero. => Because the 64 bit IDE does (on Windows) not have native extended).
But the 4.x should have that solved (IIRC I implemented that before the release of 4.0, but would need to double check the exact time).

If you did not cross debug, the it should have been ok. In a 64 bit project this compiles to double, which should work.

If you used gdb as debugger, I would expect it to show the correct value, but I don't know all issues in every version of gdb. So I can't really tell.

If you compiled with optimization -O2 or higher) then all variables may be shown wrong at some times, and right at other times. (debug info is not correctly generated at that level).


There is another option, though it wouldn't explain the wrong result in the end.

If you compiled the debug build with -gtt  (2 3 or 4 t, not sure, need to check). With the right amount of t (and it may combine that with -gt in other configs, if you have) then variables are initialized to 0 for such a build, but not for other builds.

[n7800]

If you compiled the debug build with -gtt  (2 3 or 4 t, not sure, need to check). With the right amount of t (and it may combine that with -gt in other configs, if you have) then variables are initialized to 0 for such a build, but not for other builds.

I was just about to let the author know that there's a "-gt" option for adding "garbage" to local variables to try and help find these kinds of bugs:

Code: [Select]

-gt        Trash local variables (to detect uninitialized uses; multiple 't' changes the trashing value)

I didn't know that specifying "-gtttt" (or "-gt" four times – I checked) actually fill the data with zeros! And the multiple places where options are inherited actually add up, making it impossible to predict the exact number. IMO, given the option's purpose, this is a bug!

But I see that I can reset this option before using it. Thanks, now I'll know to use this to be safe:

Code: [Select]

-gt- -gt
By the way, this also means I can be guaranteed to have zeroed local variables if I use this?

Code: [Select]

-gt- -gtttt

[Martin_fr]

And the multiple places where options are inherited actually add up, making it impossible to predict the exact number. IMO, given the option's purpose, this is a bug!

Code: Text  [Select][+][-]

1. -gt- -gt

The -gt- gives you a clean start.

-- EDIT:

Somehow skipped your last line: Yes, it does.

But, as the documented intend is to find uninitialized values, I would not rely upon it.

Mind, that -gt also initializes strings for result.

function u: string; begin {} end;

returns: "uninitialized function result in function u:AnsiString;"

And so you don't know what else future fpc versions will add. And, if they add something you don't expect...

[BildatBoffin]

I think the language should define that locals are always default initialized. The idea is that the optimizer would be able to drop the implicit initializer it it's dead (thx to dead-code-elimination, aka DCE). Bonus: you can drop the warning, you dont have to bother anymore.

Unfortunately the problem we can observe is that FPC DCE pass only works from -O2 (https://godbolt.org/z/9PeTooevh)

[n7800]

Mind, that -gt also initializes strings for result.

function u: string; begin {} end;

returns: "uninitialized function result in function u:AnsiString;"

Right, I forgot about that interesting feature. Incidentally, it raises questions:
* Why aren't local string variables initialized the same way?
* Why doesn't this work with string "out" arguments?
* Why doesn't this work if the result is a short string (ShortString or String[10])? Theoretically, the text might not fit, but that's not really important.

[PascalDragon]

I think the language should define that locals are always default initialized. The idea is that the optimizer would be able to drop the implicit initializer it it's dead (thx to dead-code-elimination, aka DCE). Bonus: you can drop the warning, you dont have to bother anymore.

No, the language will not do that.
And your idea with dead-code-elimination would only work with -O3 or better, because only then the data flow analyser is enabled.

[BildatBoffin]

-O3!, that's even worse than I thought. So if you default initialize by defaut the code will be sometime slower, unless you choose -O3. I'd say let's the compiler do the job then. People want safe code by default after all. That's a bit paradoxical if you follow me. The compiler is able but this is just not done implictly right now (default init).

[440bx]

No, the language will not do that.

IMO, it would be very useful to have the _option_ of telling FPC to initialize locals to zero.

Additionally, I find it peculiar that an option (-gt if I remember correctly) exists to put garbage in locals and parameters (affecting parameters... what an atrocity!!!.)  If there is an option to put garbage in locals then it follows that there should probably be an option to zero out the locals (which is much more useful.)

Anyway... I know that's not going to happen... it's too helpful and makes too much sense. (yes, that's sarcasm.)

[LeP]

-O3!, that's even worse than I thought. So if you default initialize by defaut the code will be sometime slower, unless you choose -O3. I'd say let's the compiler do the job then. People want safe code by default after all. That's a bit paradoxical if you follow me. The compiler is able but this is just not done implictly right now (default init).

But how much I love Delphi, 
it doesn't have these controversies.
You can't initialize a local variable (in Delphi, the initialization statement doesn't compile). Only by code. I love it.
And the compiler warns you (and may even generate a compilation error) if you use uninitialized variables.
And if someone does cheat, well, I'd say they're asking for it.

There is no issue, no safe failing, nothing.

[valdir.marcos]

Local variables must always be initialized. Sometimes they accidentally end up zero, but this is just a coincidence.

Only global variables and class fields are guaranteed to be zero.

Documentation: https://www.freepascal.org/docs-html/current/ref/refse24.html

Thanks.