Re^5: "goto" memory leak

"goto creates spurious scopes".

No, goto doesn't create scopes, spurious or otherwise. There aren't any hidden or misbehaving scopes here. It's a bit like the following code:

while (1) {
    $i = 0;
    my @a;
  again:
    push @a, 1;
    goto again if $i++ < 1000;
}
[download]

In that code, there are only two scopes: the implied whole-file scope, and the while loop. The array will repeatedly have 1000 elements pushed on it, then be emptied.

The goto just moves execution around to various places within the one scope.

Perhaps the confusion is seeing 'my' as just a compiler declaration, like 'int' is in C; it's not; its something that has a runtime effect as well as a compile-time effect. If you repeatedly execute the 'my' without ever leaving the scope which that 'my' is embedded in, then that runtime effect will accumulate.

Dave.

Comment on Re^5: "goto" memory leak Download Code

Replies are listed 'Best First'.
Re^6: "goto" memory leak by jethro (Monsignor) on Mar 31, 2016 at 13:03 UTC
Thanks, much clearer now what is happening. Still my argument stands, a bazillion code snippets to free the same single memory location is (at least from the perspective of the script writer) a memory leak. The questions is only if it is advisable to fix it since the fix would probably incur a heavy runtime cost. It will only affect long running polling code in a few specific cases (for example microcontroller scripts to measure environmental stuff could fall into the trap). It is avoidable but the program writer would need to know information about an implementation detail of "my" that is not in the man pages at the moment.	[reply]
Re^7: "goto" memory leak by Anonymous Monk on Mar 31, 2016 at 14:36 UTC
If it's any easier, think of `my` as `malloc()`. Inside a while loop, the `my` variable goes out of scope each iteration, so the storage may be reclaimed. To get the same effect with a goto loop, you'll need explicit block scoping: `again: { my $h; } goto again;` [download]	[reply] [d/l] [select]