[PHP-DEV] Bus Error with restore_error_handler() in destructor

2004-05-11 Thread Timm Friebe
[EMAIL PROTECTED]:~/devel/php/tests > cat tick.php [EMAIL PROTECTED]:~/devel/php/tests > php-dev tick.php Bus error (core dumped) - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.0.0RC2: Why is DEBUG_FILE_UPLOAD always on now?

2004-05-11 Thread Michael Sisolak
> > would make more sense instead. Having a form with an empty upload > > field shouldn't be a PHP system level error should it? Isn't that > > really something for the script to handle? > > Yes, the #ifdef's should be an #if... then all is well. I just > committed a fix to CVS, can you please v

[PHP-DEV] Segfault with error callback

2004-05-11 Thread Timm Friebe
$ php -r 'function e($code, $msg, $file, $line, &$context) { } set_error_handler("e"); trigger_error("Hello");' Notice: Hello in Command line code on line 1 Segmentation fault (core dumped) Affected: PHP4, PHP5. Does not occur when & before $context is omitted. - Timm -- PHP Internals - PHP Ru

Re: [PHP-DEV] 5.0.0RC2: Why is DEBUG_FILE_UPLOAD always on now?

2004-05-11 Thread Derick Rethans
On Tue, 11 May 2004, Michael Sisolak wrote: > would make more sense instead. Having a form with an empty upload > field shouldn't be a PHP system level error should it? Isn't that > really something for the script to handle? Yes, the #ifdef's should be an #if... then all is well. I just committ

[PHP-DEV] 5.0.0RC2: Why is DEBUG_FILE_UPLOAD always on now?

2004-05-11 Thread Michael Sisolak
For 5.0.0RC2 in main/rfc1867.c this code was introduced: #define DEBUG_FILE_UPLOAD ZEND_DEBUG As a result even Release builds of 5.0.0RC2 are reporting file upload errors as E_NOTICE errors. This includes when a form is submitted with an optional file upload field that has not been specified (yo

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Sebastian Bergmann
Timm Friebe wrote: > Aren't optional parameters and allowing NULL for typehints two > different pairs of shoes? IMHO, they are. And should stay that way. Unfortunately the only way we currently have to denote a class-hinted parameter as optional is Class $object = null :-( -- Sebasti

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Hans Lellelid
Hi, Timm Friebe wrote: Jason, I know how to build a workaround; but this is just kludgy. Marcus complained in his original mail that he was "annoyed" by the fact of having to check on a type-hinted parameter being NULL. How about I suggest I'm annoyed about having to check non-type-hinted parame

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Christian Schneider
Jason Garber wrote: public static function forName($name, $c = NULL) { if(is_null($c)) //... elseif($c instanceof ClassLoader) //... else //Throw an error Error handling can be boring/tricky/cluttering and that's why most people will simply omit it o

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Timm Friebe
On Tue, 2004-05-11 at 14:36, Jason Garber wrote: > Consider this below: [...] > class UserClass{ > public static function forName($name, $c = NULL) { >if(is_null($c)) > //... >elseif($c instanceof ClassLoader) > //... >else > //Throw an erro

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Timm Friebe
On Tue, 2004-05-11 at 14:23, Andi Gutmans wrote: > At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote: [...] > >Will this affect optional arguments? I.e., will the following still > >work? [...] > Nope, why would it work? If we make the type hint strict (which I think we > should) then you can't defin

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Jason Garber
Consider this below: At 5/11/2004 03:23 PM +0300, Andi Gutmans wrote: At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote: On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote: > I think it's hard to put closure on this type hints issue. [...] > As no good syntax has been found for the less common case of a

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Andi Gutmans
At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote: On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote: > I think it's hard to put closure on this type hints issue. [...] > As no good syntax has been found for the less common case of allowing > NULL's, I think the best solution for now is not to allow nul

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Jevon Wright
If so, maybe allow the type hint to always succeed, if it's got NULL as the default parameter? (that way foo() wouldn't act differently to foo(NULL), even though they both mean the same thing, ignoring the type hint) Jevon - Original Message - From: "Timm Friebe" <[EMAIL PROTECTED]> To:

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Timm Friebe
On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote: > I think it's hard to put closure on this type hints issue. [...] > As no good syntax has been found for the less common case of allowing > NULL's, I think the best solution for now is not to allow null in the > regular type hint syntax, and have

Re: [PHP-DEV] [RFC] Type hints

2004-05-11 Thread Andi Gutmans
At 02:21 PM 5/10/2004 -0400, Hans Lellelid wrote: Andi Gutmans wrote: As no good syntax has been found for the less common case of allowing NULL's, I think the best solution for now is not to allow null in the regular type hint syntax, and have people who want to allow NULL's not use type hints