ID: 26063
Comment by: mario-adds-a-notice at erphesfurt dot de
Reported By: mario at erphesfurt dot de
Status: Bogus
Bug Type: Arrays related
Operating System: Debian GNU/Linux, glibc2.3
PHP Version: 5CVS-2003-10-31 (dev)
New Comment:

(the "Add Comment" behaves rather strange here)

Now what is going to happen on that thing? I've visited the CVSweb and
of course noticed, that this inconsistency was also in the PHP 4.3.x
tree (but resolved now).

What is going to happen to PHP5? Will it enforce strict types like the
php5beta2 demonstrates here, or will the support for "implicit
typecasting" (like the current PHP doentation describes it) come

I don't see the problem with NULL being automatically casted to an
empty array(). Even if this is no longer the desired behaviour, a
E_NOTICE would be enough, wouldn't it? Why did the well-known and
established behaviour needed to terminate?

The PHP manual actually described what happened in
[url][/url] (the typecasting of "false" to
"array(0=>false)") quite well. If strong-typing
now gets standard, this should go into the NEWS file and into the PHP
manual. The E_WARNING and function failure right now isn't mentioned

Previous Comments:

[2003-10-31 16:52:47] [email][/email]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the doentation available at
[url][/url] and the instructions on how to report
a bug at [url][/url]

As with all other functions in PHP, when invalid parameters are passed
E_WARNING is generated. E_ERROR is intended for unrecoverable errors,
such as p errors.


[2003-10-31 15:29:23] mario at erphesfurt dot de

see also:


The array_merge() fix introduced into beta2 broke my scripts, 'cause
relied upon array_merge() to return something even if some of the
parameters were undef.

I used to merge values into my arrays that way, even if it was unclear
wether there was previously data in it:

$my_array = array_merge(
"fill_up" => "if_unset",
"this" => "too",

Which now doesn't work any longer. - this requires some code bloat to
work around now (introducing a user-level array_merge).

I don't believe the current
addresses the problem described in #25494, it now just fails and sends
eventual paramaters of PHP:ewiki_merge() to hell, making it
to previous versions (PHP4,beta1).

Why wasn't just a warning message sufficient?!

If you guys really like to change the way that PHP function was used,
you could replace E_WARNING with E_ERROR inside the array.c on line
2222 -
this would be less bogus than a _warning_ message that silently kills



Edit this bug report at [url][/url]