Re: self contains no data

On Thu, 2012-09-13 at 15:38 +0200, Nick Wellnhofer wrote:
> On 13/09/2012 15:21, Bruce Miller wrote:
> > On 09/13/2012 05:49 AM, Nick Wellnhofer wrote:
> >> On 13/09/2012 00:33, Bruce Miller wrote:
> >>> I did find something curious.  So, XML::LibXML nodes are
> >>> references to integers.  I don't know if those numbers "mean"
> >>> anything --- in ancient times, they were constant, and
> >>> you could test node equality by $$a == $$b.
> >>> At some point (an update related to thread safety?),
> >>> they're no longer constant, and there's a specific
> >>> method $a->isSameNode($b).  Would be interested in the back-story.
> >>
> >> These numbers are raw C pointers.
> >
> > Ah, I'd suspected that....
> > but they're actually moving around a bit in modern C?  interesting...
> > [If I fetch the "same" nodes from a document at several points
> > in the program, I'll get different values]
> 
> That seems strange indeed. I can't remember the internals of 
> XML::LibXML, but maybe it's normal. Different values across program runs 
> are expected because of address space layout randomization.

Perl Object(LibXML proxyptr(libxml2 nodeptr))

If the Perl Object goes out of scope the proxyptr is thrown away and a
new one created when you access that node again.

Normal, although unhelpful, behaviour.

A pointer is a fixed size, so I suspect different "lengths" are actually
just leading zeros being stripped. I wouldn't expect to have a bag of
some 32 bit and some 64 bit pointers on the same server!

/Tim.

_______________________________________________
Perl-XML mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJQUeeFAAoJECwwMWpSkLVcpTAIALzOZO8LSZ9CqI/ji1otgLYz
sh5nsYwkFYDRV29BqJiaIHEUTmr7H0NKnCygxMNVPiGdvwqGB7S6uQft+cpO+336
/kiLhleZ8tEgNY57D0ez4huVxjD3WBRNRI3TOYHsiJke/Ge1CVnaQGWJNzOKIO8w
ZV1Xcm6QcuwWqh4Cd8Tt4Y8nnC5yRRzEoir2yHO6kue92quvrGtv0ZC45y4BEpck
T+wQTgmP7CCE9lDzt2OjQOmhe5vlI5cuvdCEBEWhlvSE8mcbKp+3RwS+CvPWND05
TByh3Wr6oBZhubZG11XLE7dnbqiVUSqAN0asTN3WbkxPycHgV4TZH6Aa3z0JKRg=
=5785
-----END PGP SIGNATURE-----