Re: [PHP-DEV] Moving extensions to PECL

If I may, I'd like to suggest that if you want to emphasize PEAR in PHP5, that someone should look at bug 20933, to either verify that it is a bug, or make it clear that this new behavior is intended. (The bug is about isset() on a string subset like $a{1} always returning false.) Only because at

Re: [PHP-DEV] $scalar{index} syntax

#x27;s the more correct way to do $string[2] to > make it clear that it is a character offset. This has been supported for > years and will not go away. > > -Rasmus > > On Tue, 10 Dec 2002, Brad Bulger wrote: > > > > > trying to fix bugs in some PEAR code, i notice

[PHP-DEV] $scalar{index} syntax

trying to fix bugs in some PEAR code, i noticed the person used a way of getting at the individual characters in a string: $string{2} === substr($string,2,1) is that old syntax or something? is there any reason to expect it to work in future versions? thanks -- PHP Development Mailing List

[PHP-DEV] overridden php.ini directives in CLI version

shouldn't 'output_buffering' be overridden to 0 (off) in the CLI SAPI? doesn't help to override 'implicit_flush' but not that one. especially since there's no way to turn off the ini-level output buffering from a script. you can't end it with ob_end_*() and you can't set it with ini_set(). wherea

[PHP-DEV] cvsclean removes pear/PEAR on OS X 10.2

I think this is the darned case-insensitivity causing a problem again. the pear/.cvsignore file lists 'pear' - meaning the installer, presumably - but when cvsclean does a remove of it, it ends up removing the PEAR directory. (this came up because the 10.2 upgrade installed a too-new version of

[PHP-DEV] ZEND_PUTC question

I was looking at compile warnings for 4.3, and came across this in Zend/zend.h /* output support */ #define ZEND_WRITE(str, str_len)zend_write((str), (str_len)) #define ZEND_PUTS(str) zend_write((str), strlen((str))) #define ZEND_PUTC(c)zend_write(&(c),

Re: [PHP-DEV] on the subject of overloading: __call()

On Sun, 17 Nov 2002, Stanislav Malyshev wrote: > BB>> related topic: in the current state of ze2, there are several ways to > BB>> call methods directly that can't be emulated by call_user_func() - > BB>> calling self::method() for instance, or the visibility of $this if > BB>> you call class::met

[PHP-DEV] on the subject of overloading: __call()

was there discussion about the interaction of __call() and methods which declaring their arguments as references? there's no way at present to make this work, as far as i can tell. seems like it could just be a documented limitation, but i thought i'd check. related topic: in the current state of

Re: [PHP-DEV] $HTTP_RAW_POST_DATA

On Sun, 10 Nov 2002, Rasmus Lerdorf wrote: > Hrm.. Ok, actually Hartmut changed this recently. See: > > >http://cvs.php.net/diff.php/php4/main/php_content_types.c?login=2&r1=1.21&r2=1.22&ty=u > > It works when you turn on always_populate_raw_post_data, right? kind of. it doesn't quite follow

[PHP-DEV] overload() crashes in ZE2

trying to build CVS version with ZendEngine2 and use the overload extension. PHP crashes with a bus error on the call to overload(). it's a hash table problem, over my head for sure. i can't get this to work at all and wonder if it's a Darwin(OS X) issue. has anyone else run into this? this is t