Bug #71527 for PHP-Include: Declaring variables issue introduced in .34

Fri Oct 07 14:13:36 2011 DERRICK.A.SHIELDS [...] saic.com - Ticket created

Subject:	Declaring variables issue introduced in .34
Date:	Fri, 7 Oct 2011 14:13:26 -0400
To:	<bug-PHP-Include [...] rt.cpan.org>
From:	"Shields, Derrick A." <DERRICK.A.SHIELDS [...] saic.com>

Hi, I recently upgraded from PHP::Include .33 to .34 and am encountering an issue with variable declarations. Here's my scenario: I have Apache with two perl filters using PerlFixupHandler. I use include_php_vars to include a global configuration file into both filters. The problem: With the upgrade to .34, one of the filters will now fail to compile with many errors of "Global symbol X requires explicit package name". After turning on DEBUG, what I see is that the first filter to get compiled compiles correctly because the variables are properly lexically scoped (my $var = ...). But the second filter fails because the variables aren't declared with "my" and are therefore package variables. Looking at the new Vars.pm code, I see there is now code to attempt to be smart about avoiding declaring a variable multiple times using the declared_vars hash. But in the case of Apache with multiple filters in separate files, apparently this hash is shared resulting in only the first file getting the proper declaration. My quick fix: For a quick fix, I simply commented out the line which adds the variable to the declared_vars hash, which forces the "my" qualifier every time like in version .33. I just wanted to make you aware of this issue for a proper fix. Derrick Shields

Fri Oct 07 15:44:04 2011 ambs [...] cpan.org - Correspondence added

Hello, How is your code running? mod_perl? with multiple threads? Just to try to find a solution other than adding a switch the the command line function... :) Cheers On Fri Oct 07 14:13:36 2011, DERRICK.A.SHIELDS@saic.com wrote: Show quoted text

> Hi, > > > > I recently upgraded from PHP::Include .33 to .34 and am encountering an > issue with variable declarations. Here's my scenario: > > > > I have Apache with two perl filters using PerlFixupHandler. I use > include_php_vars to include a global configuration file into both > filters. > > > > The problem: > > > > With the upgrade to .34, one of the filters will now fail to compile > with many errors of "Global symbol X requires explicit package name". > After turning on DEBUG, what I see is that the first filter to get > compiled compiles correctly because the variables are properly lexically > scoped (my $var = ...). But the second filter fails because the > variables aren't declared with "my" and are therefore package variables. > > > > Looking at the new Vars.pm code, I see there is now code to attempt to > be smart about avoiding declaring a variable multiple times using the > declared_vars hash. But in the case of Apache with multiple filters in > separate files, apparently this hash is shared resulting in only the > first file getting the proper declaration. > > > > My quick fix: > > > > For a quick fix, I simply commented out the line which adds the variable > to the declared_vars hash, which forces the "my" qualifier every time > like in version .33. I just wanted to make you aware of this issue for > a proper fix. > > > > Derrick Shields >

Fri Oct 07 15:44:05 2011 The RT System itself - Status changed from 'new' to 'open'

Fri Oct 07 16:36:12 2011 DERRICK.A.SHIELDS [...] saic.com - Correspondence added

Subject:	RE: [rt.cpan.org #71527] Declaring variables issue introduced in .34
Date:	Fri, 7 Oct 2011 16:36:02 -0400
To:	<bug-PHP-Include [...] rt.cpan.org>
From:	"Shields, Derrick A." <DERRICK.A.SHIELDS [...] saic.com>

Hi, Yes, mod_perl with linux default worker strategy of prefork (not threaded). Derrick Show quoted text

-----Original Message----- From: rt-cpan-org-return@perl.org [mailto:rt-cpan-org-return@perl.org] On Behalf Of Alberto Simões via RT Sent: Friday, October 07, 2011 3:44 PM To: Shields, Derrick A. Subject: [rt.cpan.org #71527] Declaring variables issue introduced in .34 <URL: https://rt.cpan.org/Ticket/Display.html?id=71527 > Hello, How is your code running? mod_perl? with multiple threads? Just to try to find a solution other than adding a switch the the command line function... :) Cheers On Fri Oct 07 14:13:36 2011, DERRICK.A.SHIELDS@saic.com wrote:

> Hi, > > > > I recently upgraded from PHP::Include .33 to .34 and am encountering an > issue with variable declarations. Here's my scenario: > > > > I have Apache with two perl filters using PerlFixupHandler. I use > include_php_vars to include a global configuration file into both > filters. > > > > The problem: > > > > With the upgrade to .34, one of the filters will now fail to compile > with many errors of "Global symbol X requires explicit package name". > After turning on DEBUG, what I see is that the first filter to get > compiled compiles correctly because the variables are properly lexically > scoped (my $var = ...). But the second filter fails because the > variables aren't declared with "my" and are therefore package variables. > > > > Looking at the new Vars.pm code, I see there is now code to attempt to > be smart about avoiding declaring a variable multiple times using the > declared_vars hash. But in the case of Apache with multiple filters in > separate files, apparently this hash is shared resulting in only the > first file getting the proper declaration. > > > > My quick fix: > > > > For a quick fix, I simply commented out the line which adds the variable > to the declared_vars hash, which forces the "my" qualifier every time > like in version .33. I just wanted to make you aware of this issue for > a proper fix. > > > > Derrick Shields >

Sun Nov 06 09:06:21 2011 ambs [...] cpan.org - Correspondence added

Hello, Derrick This wasn't yet fixed, right? :-| Sorry, I forgot it, and now I am kind lost :) Cheers Alberto On Fri Oct 07 16:36:12 2011, DERRICK.A.SHIELDS@saic.com wrote: Show quoted text

> Hi, > > Yes, mod_perl with linux default worker strategy of prefork > (not threaded). > > Derrick > > -----Original Message----- > From: rt- > cpan-org-return@perl.org [mailto:rt-cpan-org-return@perl.org] On > Behalf Of Alberto Simões via RT > Sent: Friday, October 07, 2011 3:44 > PM > To: Shields, Derrick A. > Subject: [rt.cpan.org #71527] Declaring > variables issue introduced in .34 > > <URL: > https://rt.cpan.org/Ticket/Display.html?id=71527 > > > Hello, > > How is > your code running? mod_perl? with multiple threads? > Just to try to > find a solution other than adding a switch the the > command line > function... :) > > Cheers > > > On Fri Oct 07 14:13:36 2011, > DERRICK.A.SHIELDS@saic.com wrote:

> > Hi, > > > > > > > > I recently

> upgraded from PHP::Include .33 to .34 and am encountering an

> > issue

> with variable declarations. Here's my scenario:

> > > > > > > > I

> have Apache with two perl filters using PerlFixupHandler. I use

> >

> include_php_vars to include a global configuration file into both

> >

> filters.

> > > > > > > > The problem: > > > > > > > > With the upgrade

> to .34, one of the filters will now fail to compile

> > with many

> errors of "Global symbol X requires explicit package name".

> > After

> turning on DEBUG, what I see is that the first filter to get

> >

> compiled compiles correctly because the variables are properly > lexically

> > scoped (my $var = ...). But the second filter fails

> because the

> > variables aren't declared with "my" and are therefore

> package variables.

> > > > > > > > Looking at the new Vars.pm code, I

> see there is now code to attempt to

> > be smart about avoiding

> declaring a variable multiple times using the

> > declared_vars hash.

> But in the case of Apache with multiple filters in

> > separate files,

> apparently this hash is shared resulting in only the

> > first file

> getting the proper declaration.

> > > > > > > > My quick fix: > > > > > > > > For a quick fix, I simply commented out the line which adds the

> variable

> > to the declared_vars hash, which forces the "my" qualifier

> every time

> > like in version .33. I just wanted to make you aware of

> this issue for

> > a proper fix. > > > > > > > > Derrick Shields > >