Hi,

Recently moved from 5.2 to 5.3.

Now Apache will crash on loading pretty much all my pages with this in the 
error report;

szAppName : httpd.exe szAppVer : 2.2.14.0 szModName : php5ts.dll
szModVer : 5.3.1.0 offset : 0000c266

Eventually found out how it happens.

If I pass to a function an undefined variable as per example;

function testing($var1,$var2){
return 1;
}

echo testing($undefined1,$undefined2);

It will crash. No error in Apache log, no error in PHP log.

If I define $undefined2 before calling testing() then it won't crash.

Whether I define $undefined1 or not (strangely, if not strange enough 
already) doesn't make any difference, only causes a crash on the second or 
higher variable in the function definition.

Whether or not I specify $var2 = null or any other value in the function 
definition; it will still crash if $undefined2 is not previously defined.

Looking at the changes between 5.2 and 5.3 ; I assume this problem has 
spawned from this reported change

"The newer internal parameter parsing API has been applied across all the 
extensions bundled with PHP 5.3.x. This parameter parsing API causes 
functions to return NULL when passed incompatible parameters. There are some 
exceptions to this rule, such as the get_class() function, which will 
continue to return FALSE on error"



Now; I'm sure you may say, well that's just bad coding practice, you should 
always define your variables before calling them. Perhaps that may be true; 
but from the many years that I have constructed my system , I have depended 
on this behaviour and it suits me well. If I am to change the way I code; 
then it will take a little while for me to fix this issue.


So I guess I am just asking at this stage if anyone can confirm the issue at 
hand; then I suppose I will submit a PHP bug report and hope something can 
be done.

Appreciate any help,


Jett 

El 04/03/2010 6:07, Jett escribi�/wrote:
> szAppName : httpd.exe szAppVer : 2.2.14.0 szModName : php5ts.dll
> szModVer : 5.3.1.0 offset : 0000c266
>
> Eventually found out how it happens.
>
> If I pass to a function an undefined variable as per example;
>
> function testing($var1,$var2){
> return 1;
> }
>
> echo testing($undefined1,$undefined2);
>
> It will crash. No error in Apache log, no error in PHP log.
>
> If I define $undefined2 before calling testing() then it won't crash.
>
> Whether I define $undefined1 or not (strangely, if not strange enough
> already) doesn't make any difference, only causes a crash on the second or
> higher variable in the function definition.
>
> Whether or not I specify $var2 = null or any other value in the function
> definition; it will still crash if $undefined2 is not previously defined.
>
> Looking at the changes between 5.2 and 5.3 ; I assume this problem has
> spawned from this reported change
>
> "The newer internal parameter parsing API has been applied across all the
> extensions bundled with PHP 5.3.x. This parameter parsing API causes
> functions to return NULL when passed incompatible parameters. There are some
> exceptions to this rule, such as the get_class() function, which will
> continue to return FALSE on error"
>
>
>
> Now; I'm sure you may say, well that's just bad coding practice, you should
> always define your variables before calling them. Perhaps that may be true;
> but from the many years that I have constructed my system , I have depended
> on this behaviour and it suits me well. If I am to change the way I code;
> then it will take a little while for me to fix this issue.
>
>
> So I guess I am just asking at this stage if anyone can confirm the issue at
> hand; then I suppose I will submit a PHP bug report and hope something can
> be done.
>
> Appreciate any help,

No crash for me (32-bit Windows Server 2003, PHP 5.3.0 running as Apache 
2.2 module). And I think I would have noticed so because I mistype 
variable names all the time.

Have you tried a bare PHP setup with no extensions loaded?


-- 
-- http://alvaro.es - �lvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programaci�n web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

Jett wrote:
> Hi,
> 
> Recently moved from 5.2 to 5.3.
> 
> Now Apache will crash on loading pretty much all my pages with this in the 
> error report;
> 
> szAppName : httpd.exe szAppVer : 2.2.14.0 szModName : php5ts.dll
> szModVer : 5.3.1.0 offset : 0000c266
> 
> Eventually found out how it happens.
> 
> If I pass to a function an undefined variable as per example;
> 
> function testing($var1,$var2){
> return 1;
> }
> 
> echo testing($undefined1,$undefined2);
> 
> It will crash. No error in Apache log, no error in PHP log.
> 
> If I define $undefined2 before calling testing() then it won't crash.
> 
> Whether I define $undefined1 or not (strangely, if not strange enough 
> already) doesn't make any difference, only causes a crash on the second or 
> higher variable in the function definition.
> 
> Whether or not I specify $var2 = null or any other value in the function 
> definition; it will still crash if $undefined2 is not previously defined.
> 
> Looking at the changes between 5.2 and 5.3 ; I assume this problem has 
> spawned from this reported change
> 
> "The newer internal parameter parsing API has been applied across all the 
> extensions bundled with PHP 5.3.x. This parameter parsing API causes 
> functions to return NULL when passed incompatible parameters. There are some 
> exceptions to this rule, such as the get_class() function, which will 
> continue to return FALSE on error"
> 
> 
> 
> Now; I'm sure you may say, well that's just bad coding practice, you should 
> always define your variables before calling them. Perhaps that may be true; 
> but from the many years that I have constructed my system , I have depended 
> on this behaviour and it suits me well. If I am to change the way I code; 
> then it will take a little while for me to fix this issue.
> 
> 
> So I guess I am just asking at this stage if anyone can confirm the issue at 
> hand; then I suppose I will submit a PHP bug report and hope something can 
> be done.
> 
> Appreciate any help,
> 
> 
> Jett 
> 
> 

Whether you've depended on this behavior for years or not, it's crappy 
coding practice.  It leaves your code open to all kinds of future 
problems - like what happens if you come along at some time and define 
the variable for another reason?  Your code should run with no messages 
when your php.ini file has:

error_reporting = E_ALL
display_errors = on

Irregardless, coding errors in your scripts should not cause Apache to 
crash.  First, ensure you are using the correct php5ts.dll; you might 
have multiple copies if it running around.  You might also check 
bugs.php.net; others have seen crashes also, but I don't see anything 
which jumps out as the exact problem you're seeing.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Found out it only happens when code is encoded with Ioncube;  still chasing 
it up with them directly,

Cheers,

-- 


"Jett" <jonjett80gmail> wrote in message 
news:4b8f4011$1@dnews.tpgi.com.au...
> Hi,
>
> Recently moved from 5.2 to 5.3.
>
> Now Apache will crash on loading pretty much all my pages with this in the 
> error report;
>
> szAppName : httpd.exe szAppVer : 2.2.14.0 szModName : php5ts.dll
> szModVer : 5.3.1.0 offset : 0000c266
>
> Eventually found out how it happens.
>
> If I pass to a function an undefined variable as per example;
>
> function testing($var1,$var2){
> return 1;
> }
>
> echo testing($undefined1,$undefined2);
>
> It will crash. No error in Apache log, no error in PHP log.
>
> If I define $undefined2 before calling testing() then it won't crash.
>
> Whether I define $undefined1 or not (strangely, if not strange enough 
> already) doesn't make any difference, only causes a crash on the second or 
> higher variable in the function definition.
>
> Whether or not I specify $var2 = null or any other value in the function 
> definition; it will still crash if $undefined2 is not previously defined.
>
> Looking at the changes between 5.2 and 5.3 ; I assume this problem has 
> spawned from this reported change
>
> "The newer internal parameter parsing API has been applied across all the 
> extensions bundled with PHP 5.3.x. This parameter parsing API causes 
> functions to return NULL when passed incompatible parameters. There are 
> some exceptions to this rule, such as the get_class() function, which will 
> continue to return FALSE on error"
>
>
>
> Now; I'm sure you may say, well that's just bad coding practice, you 
> should always define your variables before calling them. Perhaps that may 
> be true; but from the many years that I have constructed my system , I 
> have depended on this behaviour and it suits me well. If I am to change 
> the way I code; then it will take a little while for me to fix this issue.
>
>
> So I guess I am just asking at this stage if anyone can confirm the issue 
> at hand; then I suppose I will submit a PHP bug report and hope something 
> can be done.
>
> Appreciate any help,
>
>
> Jett
> 

On Thu, 04 Mar 2010 16:07:25 +1100, Jett wrote:


> Recently moved from 5.2 to 5.3.

Not smart. Many PEAR packages do not work with 5.3, HTML_Table being one 
of them. I will continue using the 5.2 lines until they do start working.
If you ask me, 5.3 is a bit of a blunder, precisely because of 
invalidating those packages.



-- 
I don't think, therefore I am not.

Deadly Dirk wrote:
> On Thu, 04 Mar 2010 16:07:25 +1100, Jett wrote:
> 
> 
>> Recently moved from 5.2 to 5.3.
> 
> Not smart. Many PEAR packages do not work with 5.3, HTML_Table being one 
> of them. I will continue using the 5.2 lines until they do start working.
> If you ask me, 5.3 is a bit of a blunder, precisely because of 
> invalidating those packages.
> 
> 
> 

Which has absolutely nothing to do with the op's problems.

PHP 5.3 works fine when set up properly.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sat, 24 Apr 2010 05:48:13 -0400, Jerry Stuckle wrote:


> Which has absolutely nothing to do with the op's problems.

That is true.

> 
> PHP 5.3 works fine when set up properly.

Problem is that you have to "set it up properly". If I have to set it up, 
it will require changes to an awful lot of my scripts, something that I 
am unwilling to do. I'll rather switch to Python. Either the modules will 
start working out of the box or I'll use something else. That's very 
simple. The elephant in the room is that nobody is using PHP 5.3, unless 
we're talking about an absolute beginner and there are ever fewer of 
those.

Well, now I've spilled it out. Unless something is done so that PEAR 
packages start working with 5.3 out of the box, I will stop using PHP 
altogether. I am just one person, but being someone who has written a 
book about PHP and used it for a long time, I think my voice matters.

I know you to be a programming purist, we had out run-ins, but this is 
serious. PHP 5.3 is a complete disaster and, unless something is done to 
fix the packages to work out of the box, PHP will wilt and shrivel into 
irrelevance. My assumption is that you are in contact with the people who 
actually make decisions about PHP and that you can talk to someone about 
that. As I've said before, I will rather abandon PHP altogether than go 
and do "a proper setup" for the PEAR packages I am using in each and 
every script I ever wrote. If long term users with vested interest start 
abandoning PHP, then PHP has a problem, whether you like it or not.

And it's not just me. I work for a company, I have an influence over what 
scripting language gets selected for application(s). I am recommending 
Python for some time now. I haven't yet made decision about ditching PHP 
entirely and rewriting a few thousand lines of the existing code, but I 
am close to that point. PHP 5.3 is a sheer and unbridled disaster which 
may bury PHP as a language.


-- 
http://mgogala.byethost5.com

Mladen Gogala wrote:
> On Sat, 24 Apr 2010 05:48:13 -0400, Jerry Stuckle wrote:
> 
> 
>> Which has absolutely nothing to do with the op's problems.
> 
> That is true.
> 
>> PHP 5.3 works fine when set up properly.
> 
> Problem is that you have to "set it up properly". If I have to set it up, 
> it will require changes to an awful lot of my scripts, something that I 
> am unwilling to do. I'll rather switch to Python. Either the modules will 
> start working out of the box or I'll use something else. That's very 
> simple. The elephant in the room is that nobody is using PHP 5.3, unless 
> we're talking about an absolute beginner and there are ever fewer of 
> those.
>

If you set it up incorrectly, then yes, you will have to change a lot of 
scripts.  Set it up properly, and that is not true.

And don't believe nobody is using PHP 5.3.  There are a lot of 
*experienced* users out there using it.  The difference is we know what 
we're doing.

I suggest you just switch to Python now.  Don't worry any more about PHP.

> Well, now I've spilled it out. Unless something is done so that PEAR 
> packages start working with 5.3 out of the box, I will stop using PHP 
> altogether. I am just one person, but being someone who has written a 
> book about PHP and used it for a long time, I think my voice matters.
> 

Please start using Python.  PEAR packages will be fixed eventually.  And 
your voice matters no more nor no less than any other programmer's.

> I know you to be a programming purist, we had out run-ins, but this is 
> serious. PHP 5.3 is a complete disaster and, unless something is done to 
> fix the packages to work out of the box, PHP will wilt and shrivel into 
> irrelevance. My assumption is that you are in contact with the people who 
> actually make decisions about PHP and that you can talk to someone about 
> that. As I've said before, I will rather abandon PHP altogether than go 
> and do "a proper setup" for the PEAR packages I am using in each and 
> every script I ever wrote. If long term users with vested interest start 
> abandoning PHP, then PHP has a problem, whether you like it or not.
> 

No, I'm not a purist.  But I write good code - so I don't run into many 
of the problems you have.  PHP 5.3 does have changes, and some of those 
result in incompatibilities with older code.  Such is the case as a 
language matures.  Admittedly, PHP has more problems than many because 
it wasn't designed well in the first place.  But that's coming.

So please - abandon PHP and go to Python.

> And it's not just me. I work for a company, I have an influence over what 
> scripting language gets selected for application(s). I am recommending 
> Python for some time now. I haven't yet made decision about ditching PHP 
> entirely and rewriting a few thousand lines of the existing code, but I 
> am close to that point. PHP 5.3 is a sheer and unbridled disaster which 
> may bury PHP as a language.
> 
> 

That's fine.  Please - use Python.  The good programmers will continue 
with PHP - and succeed.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sat, 24 Apr 2010 14:03:48 -0400, Jerry Stuckle wrote:

> That's fine.  Please - use Python.  The good programmers will continue
> with PHP - and succeed.

Good luck.



-- 
http://mgogala.byethost5.com

Mladen Gogala wrote:
> On Sat, 24 Apr 2010 14:03:48 -0400, Jerry Stuckle wrote:
> 
>> That's fine.  Please - use Python.  The good programmers will continue
>> with PHP - and succeed.
> 
> Good luck.
> 
> 
> 

No luck needed.  Just competence.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sat, 24 Apr 2010 15:17:21 -0400, Jerry Stuckle wrote:

> Mladen Gogala wrote:
>> On Sat, 24 Apr 2010 14:03:48 -0400, Jerry Stuckle wrote:
>> 
>>> That's fine.  Please - use Python.  The good programmers will continue
>>> with PHP - and succeed.
>> 
>> Good luck.
>> 
>> 
>> 
>> 
> No luck needed.  Just competence.

Without any intention of getting into "I'm smarter then you" type of 
debate with you, let me just point out a simple and easy to check fact 
that zealots usually destroy precisely the object of their unlimited 
love and devotion. Murphy has phrased it it a bit differently, but that 
would be insulting for you and, as opposed to you, I don't subscribe to 
throwing around personal insults on groups about the information 
technology.

You managed to insult me, a long term user and a proponent of PHP, all in 
the name of what can only be described as "PHP religion". Let's hope that 
there are smarter people than you on the PHP group. Plonk.



-- 
http://mgogala.byethost5.com

Mladen Gogala wrote:
> On Sat, 24 Apr 2010 15:17:21 -0400, Jerry Stuckle wrote:
> 
>> Mladen Gogala wrote:
>>> On Sat, 24 Apr 2010 14:03:48 -0400, Jerry Stuckle wrote:
>>>
>>>> That's fine.  Please - use Python.  The good programmers will continue
>>>> with PHP - and succeed.
>>> Good luck.
>>>
>>>
>>>
>>>
>> No luck needed.  Just competence.
> 
> Without any intention of getting into "I'm smarter then you" type of 
> debate with you, let me just point out a simple and easy to check fact 
> that zealots usually destroy precisely the object of their unlimited 
> love and devotion. Murphy has phrased it it a bit differently, but that 
> would be insulting for you and, as opposed to you, I don't subscribe to 
> throwing around personal insults on groups about the information 
> technology.
> 
> You managed to insult me, a long term user and a proponent of PHP, all in 
> the name of what can only be described as "PHP religion". Let's hope that 
> there are smarter people than you on the PHP group. Plonk.
> 
> 
> 

ROFLMAO!  I said NOTHING about you - other than to call you on your 
threat to change to Python.  If you are incompetent, then that is YOUR 
problem - not mine.

It doesn't make any difference how long you've used PHP.  You want to go 
to Python - please do.

We don't need noobs like you around here.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sat, 24 Apr 2010 17:33:41 -0400, Jerry Stuckle wrote:
> ROFLMAO!  I said NOTHING about you - other than to call you on your 
> threat to change to Python.  If you are incompetent, then that is YOUR 
> problem - not mine.
>
> It doesn't make any difference how long you've used PHP.  You want to go 
> to Python - please do.

It's a cheap manipulation to see if he can encourage answers he likes
better. As though we had something invested in him continuing to use
PHP.

-- 
46. If an advisor says to me "My liege, he is but one man. What can one
    man possibly do?", I will reply "This." and kill the advisor.
	--Peter Anspach's list of things to do as an Evil Overlord

On Sat, 24 Apr 2010 22:25:02 +0000, Peter H. Coffin wrote:

> It's a cheap manipulation 

Manipulation??? I stated my goals quite openly.

> to see if he can encourage answers he likes
> better.

Encourage answers? I had no idea that posting on a PHP required courage. 
Any purple hearts going around?





-- 
http://mgogala.byethost5.com

Peter H. Coffin wrote:
> On Sat, 24 Apr 2010 17:33:41 -0400, Jerry Stuckle wrote:
>> ROFLMAO!  I said NOTHING about you - other than to call you on your 
>> threat to change to Python.  If you are incompetent, then that is YOUR 
>> problem - not mine.
>>
>> It doesn't make any difference how long you've used PHP.  You want to go 
>> to Python - please do.
> 
> It's a cheap manipulation to see if he can encourage answers he likes
> better. As though we had something invested in him continuing to use
> PHP.
> 

Yea, he thinks since he co-wrote "Easy PHP Oracle", he should get 
special treatment.  It doesn't work that way.

If he prefers Python over PHP, I wish he would just go to the Python 
newsgroups and take his whining with him.

I really don't think he expected anyone to tell him to go ahead and do it :)

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Mladen Gogala <gogala.mladen@gmail.com> wrote:

> On Sat, 24 Apr 2010 05:48:13 -0400, Jerry Stuckle wrote:

<snip>

>> PHP 5.3 works fine when set up properly.
> 
> Problem is that you have to "set it up properly".

This is something PHP users should have been doing since long 
before 5.3.  Do you just use one of the stock php.ini config files 
without even taking a look?  Ah, but if you're going to use 
Oracle, or other extensions, you have to get them set up properly.  
This has been necessary for a long time.

Even for Python, Perl, or other server-side scripting languages, 
you have some setting up to do to get them to work as CGIs or, in 
the case of Apache, modules.

> If I have to
> set it up, it will require changes to an awful lot of my
> scripts, something that I am unwilling to do.

I've been using 5.3 for a while now, and I still have scripts that 
I wrote under PHP 4 that run fine without modification.

> I'll rather switch
> to Python. Either the modules will start working out of the box
> or I'll use something else. That's very simple. The elephant in
> the room is that nobody is using PHP 5.3, unless we're talking
> about an absolute beginner and there are ever fewer of those.

While this may be your experience, it is not mine.

> Well, now I've spilled it out. Unless something is done so that
> PEAR packages start working with 5.3 out of the box, I will stop
> using PHP altogether. I am just one person, but being someone
> who has written a book about PHP and used it for a long time, I
> think my voice matters. 

Personally, I don't use PEAR packages, but you should note that 
the PHP core devs aren't responsible for each and every PEAR 
package (if any at all; PEAR seems to have its own governing 
body).

If you want to make appeals, you're doing it in the wrong place.  
Head to <http://pear.php.net/> and get in contact with the 
maintainers of the packages you use.  As mentioned upthread, most 
packages will likely be updated.  In fact, you're free to 
contribute patches of your own, if you have the time and 
inclination.

There's also an official php.net news server:  <news.php.net>.

> I know you to be a programming purist, we had out run-ins, but
> this is serious. PHP 5.3 is a complete disaster and, unless
> something is done to fix the packages to work out of the box,
> PHP will wilt and shrivel into irrelevance.

Can you provide any authoritative evidence that PHP will likely 
lose a serious amount of users due to incompatible PEAR packages?  
Again though, it's unlikely that actively maintained packages will 
be incompatible for long.

> My assumption is
> that you are in contact with the people who actually make
> decisions about PHP and that you can talk to someone about that.

Why would you assume that?  I haven't seen any indications that 
this is the case.

> As I've said before, I will rather abandon PHP altogether than
> go and do "a proper setup" for the PEAR packages I am using in
> each and every script I ever wrote.

What are the problems you're having with this "proper setup" you 
seem to be dreading?

> If long term users with
> vested interest start abandoning PHP, then PHP has a problem,
> whether you like it or not. 

If this were indeed the case...

> And it's not just me. I work for a company, I have an influence
> over what scripting language gets selected for application(s).

That's nice.

> I
> am recommending Python for some time now.

Great!  Python seems to be a pretty nice language.  It's 
interesting you condemn PHP's backward compatibility, though, 
considering:

  # Python 2.5
  print 'Hello, World!\n'

  # Python 3
  print 'Hello, World!\n'

  # Whoops, SyntaxError in Python 3.
  # No more `print' statement; `print' is now a function.

I'm aware Python 3 was deliberately intended to break backward 
compatibility, I'm just being a bit facetious. :P

> I haven't yet made
> decision about ditching PHP entirely and rewriting a few
> thousand lines of the existing code, but I am close to that
> point. PHP 5.3 is a sheer and unbridled disaster which may bury
> PHP as a language. 

Is there any reason you need to upgrade to 5.3 immediately?  Also, 
there are probably many factors that need to be weighed when 
considering rewrites.  For one, what about the time it would take 
for the current devs to learn another language?  They might well 
pick up Python syntax relatively quickly, but it takes time to 
learn to use a language's standard library well.  Python's 
implementation of OOP is also quite different from PHP's.  
Basically, it will be quite some time before the devs start 
writing "pythonic" code and become "pythonistas".  This is true of 
learning any new languages.

-- 
Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

On Tue, 27 Apr 2010 09:16:33 +0000, Curtis Dyer wrote:


> I've been using 5.3 for a while now, and I still have scripts that I
> wrote under PHP 4 that run fine without modification.

OK, how do you make PEAR HTML_Table and HTML_Form work with 5.3? I was 
getting a bunch of error messages about assignment by reference and it 
wasn't working properly. I have a decent collection of code and I am in 
no mood for rewriting. That is my problem. The same goes for HTML_Table.  
If you can make it work with 5.3, I am all ears. If I have to rewrite all 
of my scripts, I will use something with better track record in 
compatibilty. It's as simple as that. So, how do you get those specific 
two packages to work? They're embedded in virtually all of my scripts and 
I will be extremely annoyed if I have to rewrite it all. As far as I am 
aware, there is no php.ini parameters that would fix that. If you are 
better informed than me, please let me know, I will forever be in your 
debt.

-- 
http://mgogala.byethost5.com

Mladen Gogala wrote:
> On Tue, 27 Apr 2010 09:16:33 +0000, Curtis Dyer wrote:
> 
> 
>> I've been using 5.3 for a while now, and I still have scripts that I
>> wrote under PHP 4 that run fine without modification.
> 
> OK, how do you make PEAR HTML_Table and HTML_Form work with 5.3? I was 
> getting a bunch of error messages about assignment by reference and it 
> wasn't working properly. I have a decent collection of code and I am in 
> no mood for rewriting. That is my problem. The same goes for HTML_Table.  
> If you can make it work with 5.3, I am all ears. If I have to rewrite all 
> of my scripts, I will use something with better track record in 
> compatibilty. It's as simple as that. So, how do you get those specific 
> two packages to work? They're embedded in virtually all of my scripts and 
> I will be extremely annoyed if I have to rewrite it all. As far as I am 
> aware, there is no php.ini parameters that would fix that. If you are 
> better informed than me, please let me know, I will forever be in your 
> debt.
> 

Report the bugs and have the package developers fix them.  Or fix them 
yourself.

The packages will catch up.

The difference is I don't use many PEAR classes - especially HTML_Table 
and HTML_Form.  I can do it better and faster in my own code.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Mladen Gogala <mgogala@no.address.invalid> wrote:

> On Tue, 27 Apr 2010 09:16:33 +0000, Curtis Dyer wrote:
> 
> 
>> I've been using 5.3 for a while now, and I still have scripts
>> that I wrote under PHP 4 that run fine without modification.
> 
> OK, how do you make PEAR HTML_Table and HTML_Form work with 5.3?

As I said in my initial reply to you (part of the portion you 
snipped), I don't use PEAR.

However, I was curious, so set up PEAR and acquired HTML_Table.  
Right off, PEAR warned that HTML_Common, the class HTML_Table 
extends, is now deprecated in favor of HTML_Common2.  However, you 
can still get HTML_Common just fine, so it's not too big a deal 
for now.

I threw together a test script using HTML_Table.  Although the 
class uses dated OOP, everything seemed to work fine.  The only 
issue I ran into was that I had to disable E_STRICT, since 
HTML_Table seems to frequently call a non-static PEAR method 
statically.

Sorry, I didn't bother trying HTML_Form.  Again, I suggest you get 
in contact with the package maintainers, since they know their own 
software best.

> I was getting a bunch of error messages about assignment by
> reference and it wasn't working properly.

I had a look at the HTML_Table methods that return by reference.  
Since it's still using the PHP 4 OO model, it's returning objects 
by reference, but such practice is unnecessary in PHP 5+ (and may 
not do what you'd expect, in some cases).  That, in and of itself, 
shouldn't cause errors, but without more information and the exact 
error messages you received, it's hard to say.

But note that HTML_Table returns references to what are supposed 
to be private properties.  This is generally bad design, since it 
leaks implementation.

Frankly, you'd be better off designing your own implementation 
that handles tables.  If you simply write a better class that 
mimics HTML_Table's interface, you might be able to get away with 
avoiding rewriting most of your code.

> [...]So, how do you get those specific two
> packages to work? They're embedded in virtually all of my
> scripts and I will be extremely annoyed if I have to rewrite it
> all.

I've already given my suggestions (Jerry, too).  You can contact 
the maintainers of the PEAR packages you use, since they're in the 
best position to affect change.  You might also simply wait for 
the maintainers to release updates on their own.  You can try to 
submit your own patches for the packages to the maintainers.

> As far as I am aware, there is no php.ini parameters that
> would fix that. If you are better informed than me, please let
> me know, I will forever be in your debt.

See above responses about contacting the maintainers of the 
packages.

-- 
Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>