Re: Reference of constants and literals

I don't quite understand your question. When you have a number, and take a reference to it, it will appear as SCALAR(0x...) in the output. If you have an array reference (or reference to any data structure), and take a reference to it, it will appear as REF(0x...). I don't see any relation to "code position", whatever you mean by that.

$ # also works for scalars this way, when you take a ref to a ref:
$ perl -wle 'print \\4'
REF(0x5043b0)
[download]

(And if you use <code>...</code> tags to delimit your code the square brackets will display correctly, and don't turn into links)

Comment on Re: Reference of constants and literals Select or Download Code

Replies are listed 'Best First'.
Re^2: Reference of constants and literals by Corion (Patriarch) on Nov 24, 2008 at 10:19 UTC
I think it's the symptom of an idea I planted in LanX' head yesterday, the idea of determining that the code is getting called from the same location because it gets passed the same (addresses of) variables. For arrays/hashes, it seems the code actually gets the same addresses of variables even though these are lexicals.	[reply]
Re^3: Reference of constants and literals by moritz (Cardinal) on Nov 24, 2008 at 10:29 UTC
That might be a nice idea for an obfuscation context, but certainly not for production code. It relies on an undocumented behaviour, here an optimization that might very well be changed in future. I think it's related to the optimization described in No garbage collection for my-variables (not sure though).	[reply]
Re^4: Reference of constants and literals by ikegami (Patriarch) on Nov 24, 2008 at 11:00 UTC
I think it's related to the optimization described in No garbage collection for my-variables (not sure though). The linked post refers to the effect of the `padsv` (`my $`) operator. Neither `padsv` nor the underlying code (`SAVECLEARSV`) is involved here. Any resemblance is coincidental. In fact, I don't think there's any reuse of allocated memory involved. I think a new memory block just happens to be allocated at the same location as a previously allocated memory block. (Upd: That's indeed what happens, as show in Re^5: Reference of constants and literals ) For example, the following code continually allocates memory blocks at the same two locations. This is not related to `my` since we're forcing `my` to continually reallocate SVs by keeping the refcount greater than 1. There is no reuse of allocated memory at all. `>perl -le"sub f{ \my $x } print f() for 1..10;" SCALAR(0x236d40) SCALAR(0x236014) SCALAR(0x236d40) SCALAR(0x236014) SCALAR(0x236d40) SCALAR(0x236014) SCALAR(0x236d40) SCALAR(0x236014) SCALAR(0x236d40) SCALAR(0x236014)` [download]	[reply] [d/l] [select]
Re^5: Reference of constants and literals by JavaFan (Canon) on Nov 24, 2008 at 11:37 UTC
Re^6: Reference of constants and literals by ikegami (Patriarch) on Nov 24, 2008 at 11:54 UTC
Re^6: Reference of constants and literals by ikegami (Patriarch) on Nov 24, 2008 at 12:48 UTC
Re^2: Reference of constants and literals by LanX (Saint) on Nov 24, 2008 at 10:46 UTC
Well it's a question of weird optimization, a constant scalar is passed in a certain snippet of code, so no need to switch the reference at runtime. This works with explicit refs like `[1,2]` and `{1,2}` but not with constants, they needlessly get at runtime a new reference, each time the loop gets there... just compare: `check(qw/ Scalarref \1 /);` OUTPUT `--- Scalarref for (1..3) { pr \1; print "\n\t"; #UPDATE for (1..3) { pr \1; } print "\n"; } REF(0x8190768) REF(0x8190744) REF(0x8190750) REF(0x8190744) REF(0x8190750) REF(0x8195394) REF(0x8190744) REF(0x8195394) REF(0x8190744) REF(0x8190768) REF(0x8195394) REF(0x8190768)` [download] each time a new ref instead of one ref Cheers Rolf	[reply] [d/l] [select]