Recent

Author Topic: local variables initialization  (Read 942 times)

440bx

  • Hero Member
  • *****
  • Posts: 3946
local variables initialization
« on: June 22, 2022, 12:03:18 am »
Hello,

I know there is a switch that causes FPC to "trash" local variables and, I was wondering if there was some option to inform FPC to zero out (instead of "trashing") all the local variables in a function.

Is there such a compiler option ?

Thank you for your help.


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: local variables initialization
« Reply #1 on: June 22, 2022, 12:30:39 am »
Well yes.... But not explicit, so not sure if future proof

Code: Text  [Select][+][-]
  1. -gt- -gtttt

-gt can have between 1 and 4 "t". And chooses one of 4 values for the trashing.
One of those values is zero. So trashing with 0 will have the effect you want...

-gt can build up. I.e.  "-gtt" or "-gt -gt" both means 2 "t". You could just give -gtttt, but if somehow there is another -gt before then you don't get zero (because you effectively have 5 "t" mod 4 means 1 "t")

-gt-  seems to clear the "t" completely.

Of course, if after your "-gt -gtttt" is any other -gt, then it breaks again.

And also, whilst I do recall having seen the 4 trash values somewhere, I do not know if that was in any official doc, and if they will forever be the same as they are now.


Trashing with 0 makes sense, if you check for uninitialized booleans. That way you trash them to false.
Testing your up with -gt and then -gtttt means you did trash the boolean once to true, and once to false. Improving chances to catch the uninitialized.


Mind, that I have also seen managed vars of type ansistring being affected by trashing.
I.e. an uninitialized ansistring (at least result) is no longer empty.

I do not know, if that happens with -gtttt
Nor which versions of fpc do that.

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: local variables initialization
« Reply #2 on: June 22, 2022, 01:07:08 am »
Thank you Martin, I appreciate the thorough reply.

I stay as far away from -gt as I can.  That thing also trashes out parameters.

It would be nice if FPC offered a compiler option to zero-out local variables (and only those!).  Just dreaming... :)

Thank you again.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: local variables initialization
« Reply #3 on: June 22, 2022, 09:28:03 pm »
Mind, that I have also seen managed vars of type ansistring being affected by trashing.
I.e. an uninitialized ansistring (at least result) is no longer empty.
An unitialized ansistring result is never guaranteed to be empty. That's why the compiler prints a warning (rather than a hint) if you read it before writing it.

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: local variables initialization
« Reply #4 on: June 23, 2022, 08:09:19 am »
Mind, that I have also seen managed vars of type ansistring being affected by trashing.
I.e. an uninitialized ansistring (at least result) is no longer empty.
An unitialized ansistring result is never guaranteed to be empty. That's why the compiler prints a warning (rather than a hint) if you read it before writing it.
Then again, string vars - and not only those -  can be initialized at declaration.
Code: Pascal  [Select][+][-]
  1. procedure someprocedure;
  2. var
  3.   s:string = '';// initialized, also for stack.
  4. begin
  5. end;
But even if you correctly use the above for all local vars, stack thrashing can be useful to catch your unexpected errors.
Maybe note initialization at declaration can slow down your code just a bit in the case of managed types.
« Last Edit: June 23, 2022, 08:19:12 am by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018