Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

use of hex-number in references

by eXile (Priest)
on Jun 09, 2004 at 00:56 UTC ( #362599=perlquestion: print w/replies, xml ) Need Help??

eXile has asked for the wisdom of the Perl Monks concerning the following question:


just out of curiosity: If I print a hashref or arrayref like this:

my $aap = {}; my $noot = []; local $\="\n"; print $aap; print $noot; __END__ HASH(0x804d170) ARRAY(0x804d23c)
what are the numbers 0x804d170 and 0x804d23c exactly? Are they memory locations? Can I directly map this to something like /dev/mem, /dev/kmem or a coredump of the process (in case I make it dump core)?

Replies are listed 'Best First'.
Re: use of hex-number in references
by Zaxo (Archbishop) on Jun 09, 2004 at 01:08 UTC

    Yes, they are memory locations and could be more or less useful with a core file. It would take a good knowledge of perl implementation details to make that meaningful. A perl built with -DDEBUGGING is probably a better investment for such an investigation.

    You can get the decimal address with print 0 | $ref;, which places $ref in numeric context. Since | acts on bitfields, $ref's target address is coerced into an unsigned integer.

    After Compline,

        Yes, it makes no difference. It looks like a reference is always unsigned in numeric context, since 0+ gives the same result as 0|, while 0x8nnnnnnn would be negative taken as a 32 bit signed integer.

        After Compline,

Re: use of hex-number in references
by dave_the_m (Monsignor) on Jun 09, 2004 at 01:07 UTC
    Yes, they correspond to the address of the SV structure which holds the hash or array.


      And you can actually get to them using Devel::Pointer.

      use Devel::Pointer; $a = 'Hello World'; $scalar_ref = \$a; print "Scalar Ref is $scalar_ref\n"; $what = unsmash_sv(0+$scalar_ref); print "$scalar_ref is actually >$what<\n"; __DATA__ Scalar Ref is SCALAR(0x1ab2734) SCALAR(0x1ab2734) is actually >Hello World<



      This is probably a silly questions, but my inexperience with memory management forces me to post it. ;-)

      So, those references are actually pointers which map directly to system memory. However, if the systems moves around memory zones (i.e. it puts something on the swap file/partition), how can they remain valid?

      Thanks, Michele.

        The addresses programs use are virtual addresses. These are translated to real (physical) addresses by the OS and/or the CPU transparently to the program.

        The following extract from here says it better.

        Address translation

        This means the virtual addresses generated by a program are different from the physical addresses that go onto the address bus; to the memory chips. The translation of virtual addresses to physical addresses is performed by special hardware inside the CPU called a memory management unit (MMU).

        Address translation can be used for the kernel as well as the tasks. This lets you link the kernel to run at a specific address, but load the kernel anywhere in memory.

        Besides address translation, the MMU usually provides memory protection. Ranges of memory can be made to cause a page fault or general protection fault by any combination of writing to the memory range, accessing the memory range in any way (read, write, execute), access to the memory range by code running at user privilege (ring 3).

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://362599]
Approved by Zaxo
Front-paged by broquaint
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2022-09-26 03:43 GMT
Find Nodes?
    Voting Booth?
    I prefer my indexes to start at:

    Results (116 votes). Check out past polls.