Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of torsten.foertsch@gmx.net
 designates 213.165.64.20 as permitted sender)
From: Torsten Foertsch <torsten.foertsch@gmx.net>
To: modperl@perl.apache.org
Subject: Re: [MP2] possible pnotes bug?
Date: Wed, 15 Mar 2006 19:47:15 +0100
User-Agent: KMail/1.7.1
Cc: Perrin Harkins <perrin@elem.com>,
	Geoffrey Young <geoff@modperlcookbook.org>,
	Tom Schindl <tom.schindl@bestsolution.at>,
	"Philippe M. Chiasson" <gozer@ectoplasm.org>,
	Frank Wiles <frank@wiles.org>, dev@perl.apache.org,
	gyoung@modperlcookbook.org
References: <200601091914.13383.torsten.foertsch@gmx.net>
 <44184D9A.2010501@modperlcookbook.org>
 <1142445319.20635.5.camel@localhost.localdomain>
In-Reply-To: <1142445319.20635.5.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1180632.0QMFIy8Plb";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200603151947.22518.torsten.foertsch@gmx.net>

--nextPart1180632.0QMFIy8Plb
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 15 March 2006 18:55, Perrin Harkins wrote:
> On Wed, 2006-03-15 at 12:23 -0500, Geoffrey Young wrote:
> > I actually thing that would be somewhat common.  and as I understand
> > things, the fix would require the middle step to be
> >
> >   -- next handler
> >   my $o =3D $r->pnotes('foo');
> >   $o->set(bar =3D> 1);          # sets $o->{_bar} =3D 1
> >   $r->pnotes(foo =3D> $o);
> >
> > in order for $o to maintain it's internal state.  is that right?  if so,
> > I don't like that very much.
>
> I agree, cloning is not the answer.  What you want really want here is
> for it to behave like a normal perl variable assignment, i.e. if you
> assign a reference, it stays a reference, and if you assign a value,
> it's just a value, not a double-secret-probation reference.  I don't
> think it's a good idea to change this unless it can be done that way.

The current implementation of

  $r->pnotes(foo=3D>$x)

is halfway similar to

  $r->pnotes->{foo}=3D\$x.

Only halfway because fetching the value works as expected: $r->pnotes('foo'=
).=20
In pure Perl the exact behavior cannot be expressed.

Internally pnotes are stored in a HV. $r->pnotes without arguments returns =
a=20
reference to that HV. Hence, $r->pnotes->{foo}=3D$o works as a normal=20
assignment of a hash element:

$ perl -MDevel::Peek -e '$x=3D1; Dump($x); $h{x}=3D$x; Dump(\%h);'
SV =3D IV(0x816e598) at 0x816c6fc
  REFCNT =3D 1
  FLAGS =3D (IOK,pIOK)
  IV =3D 1
SV =3D RV(0x8178d48) at 0x8151d40
  REFCNT =3D 1
  FLAGS =3D (TEMP,ROK)
  RV =3D 0x816c744
  SV =3D PVHV(0x81699c8) at 0x816c744
=2E..
    Elt "x" HASH =3D 0x9303a5e5
    SV =3D IV(0x816e59c) at 0x8151c20
      REFCNT =3D 1
      FLAGS =3D (IOK,pIOK)
      IV =3D 1

Note that the refcounts of both IVs the first after $x=3D1 and the second i=
n %h=20
are 1. Also the IVs themself are different objects one at 0x816e598 the=20
second at 0x816e59c.

With $r->pnotes->{x}=3D$x the output is similar.

But with $r->pnotes(x=3D>$x) it changes:

SV =3D IV(0x84c0664) at 0x866099c
  REFCNT =3D 1
  FLAGS =3D (PADBUSY,PADMY,IOK,pIOK)
  IV =3D 1
SV =3D RV(0x8640b68) at 0x8651a7c
  REFCNT =3D 2
  FLAGS =3D (TEMP,ROK)
  RV =3D 0x86397ec
  SV =3D PVHV(0x86453a0) at 0x86397ec
=2E..
    Elt "x" HASH =3D 0x9303a5e5
    SV =3D IV(0x84c0664) at 0x866099c
      REFCNT =3D 2
      FLAGS =3D (PADBUSY,PADMY,IOK,pIOK)
      IV =3D 1

Now the both IVs are the same (0x84c0664) and the refcount after storing as=
 a=20
pnote is 2. And here is the problem. $r->pnotes->{x}=3D$x and $r->pnotes(x=
=3D>$x)=20
are different operations. The first stores a copy of the IV represented by=
=20
$x. The second stores the IV $x itself. This is somehow similar to *y=3D\$x:

$ perl -e '$x=3D1; *y=3D\$x; $x++; print "$y\n";'
2
$ perl -MDevel::Peek -e '$x=3D1; Dump($x); *y=3D\$x; Dump($y);'
SV =3D IV(0x816e590) at 0x816c6f4
  REFCNT =3D 1
  FLAGS =3D (IOK,pIOK)
  IV =3D 1
SV =3D IV(0x816e590) at 0x816c6f4
  REFCNT =3D 2
  FLAGS =3D (IOK,pIOK)
  IV =3D 1

I think it is a bug even in MP1.

Here the code that produces the output in error_log:

package pn;

use strict;
use Apache2::RequestRec;
use Apache2::RequestIO;
use Apache2::RequestUtil;
use Apache2::Const -compile=3D>'OK';
use Devel::Peek;

sub handler {
  my $r=3Dshift;
  my $x=3D1;
  Dump($x);
  $r->pnotes(x=3D>$x);
  Dump($r->pnotes);
  $r->print("ok\n");
  return Apache2::Const::OK;
}

1;

Devel::Peek uses buffered output at C-level. Hence, you probably have to=20
restart the server to see the actual output.

Torsten

--nextPart1180632.0QMFIy8Plb
Content-Type: application/pgp-signature

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

iD8DBQBEGGE6wicyCTir8T4RAgYDAKDD02neVX2r7LwV2+SjTnMJZ/3SwQCgsH26
VijxHwAuBx8URvXmolEDfo0=
=pN8Q
-----END PGP SIGNATURE-----

--nextPart1180632.0QMFIy8Plb--