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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
