Re: Adding a few debug helpers to php4.x

From: Date: Thu, 04 Mar 2004 07:06:12 +0000
Subject: Re: Adding a few debug helpers to php4.x
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-8364@lists.php.net to get a copy of this message
It's not quite as simple as that. To qualify dynamically loadable extensions, you will need "debug-zval / non-debug-zval" in addition to the existing debug/non-debug + zts/no-zts. Or it can be made part of debug mode, but then the API number has to be bumped, which requires a minor version change (4.3 -> 4.4). - Stig On Wed, 2004-03-03 at 22:13, Todd Ruth wrote: > Actually, I found the code reasonably clear - a kudos to someone. > The points about the footprint and performance are well taken. > Because the feature is most important before any customers see the > latest rev of product, the feature would be just as useful as > an optional part of the php build. It's already useful to do > testing with a different php build than the production build just > to have php debugging enabled. Although the feature performs > best with an added field in the zval struct, if it is considered > bad form to have an ifdef in the struct, the feature could be > implemented with a separate table. (The table would have zval > pointers as indices and allow_copies values as values. Any > pointer not in the table would be assumed to have allow_copies > set to true. The table, checks, and new functions would only > be avaiable for debug builds (or whatever build flag is most > appropriate).) > > Better? > > - Todd > > On Wed, 2004-03-03 at 12:54, Andi Gutmans wrote: > > At 09:25 PM 3/3/2004 +0100, Derick Rethans wrote: > > >On Wed, 3 Mar 2004, Todd Ruth wrote: > > > > > > > Finding those bugs when you have tens of thousands of lines of > > > > php can be a real headache. That's why I'd very much like > > > > a disallow_copies function. > > > > > >But as you demonstrated with your patch you need to modify some of the > > >basic data types that PHP uses and thus increasing memory footprint and > > >decreasing performance. It is therefore very unlikely that this will be > > >ever allowed into the PHP source. > > > > Yep, I agree with Derick. Needless to say that it's very dangerous to try > > and make sense out of the low level stuff the engine and the PHP extensions > > are doing (such as copy constructing, separating and other stuff). > > > > Andi

« previous php.internals (#8364) next »