Depending on the compiler *not* to overwrite local variables is most
certainly the wrong way to go with this. You really should create
either a global record/object, or use functions to pass around the
information you need. Expecting the operating system to keep local
variables after the area goes out of scope is just begging for errors
later on when the compiler/os treatment of said areas changes.
On 6/4/2023 1:37 PM, Steve Litt via fpc-pascal wrote:
Henry Vermaak via fpc-pascal said on Fri, 2 Jun 2023 09:38:17 +0100
On Fri, 2 Jun 2023 at 01:36, Steve Litt via fpc-pascal
<fpc-pascal@lists.freepascal.org> wrote:
fillchar(junkvar, junkvar_size, 'b');
person := modperson(person, 'Martin');
person := modperson(person2, 'Maria');
Maybe a typo? (E.g. person2 := modperson(person2, 'Maria'))
Henry
Thanks Henry!
You're right: Changing the second person := to person2 := did just what
I wanted it to do.
Because returning a local array or string as a function return in C
leads to horrible intermittents due to the local going out of scope and
relinquishing the local's stack, which can then be overwritten, I added
a procedure, a function, and a main program statement which each
consumed two million bytes of local variables, and the person and
person2 didn't get overwritten. Very cool.
When I increased the huge local vars to three million bytes, the
program segfaulted. I figure I just ran it out of stack, but until I
did, the huge local vars didn't trash the contents of person and
person2.
Thanks for your help.
SteveT
Steve Litt
Autumn 2022 featured book: Thriving in Tough Times
http://www.troubleshooters.com/bookstore/thrive.htm
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
