php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23804 passing wrong parameter count to user functions gives no warnings
Submitted: 2003-05-25 16:59 UTC Modified: 2003-05-26 13:34 UTC
Votes:6
Avg. Score:3.8 ± 1.5
Reproduced:4 of 5 (80.0%)
Same Version:4 (100.0%)
Same OS:2 (50.0%)
From: meebey@php.net Assigned:
Status: Wont fix Package: Scripting Engine problem
PHP Version: 4.3.1 OS: Debian GNU/Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: meebey@php.net
New email:
PHP Version: OS:

 

 [2003-05-25 16:59 UTC] meebey@php.net
When I pass 3 parameters to an user PHP function, that needs 2 parameters, I don't get any fatal, warning nor notice.. The function is just called and the 3. parameter ignored...

When C PHP Functions are called like mysql_connect() with a wrong parameter count, I will get a E_WARNING. It should be the same with the user functions...
ZEND_API void zend_wrong_param_count(TSRMLS_D) does this for the C functions...

Also it's the same behaviour on ZendEngine2, no fatal, warning nor notice..

here a simple script to reproduces/test the bug:
#!/usr/local/bin/php
<?php
// to be sure we get all fatal, warnings and notices
error_reporting(E_ALL);
ini_set("display_errors","1");

// declaring a function which takes _2_ parameters
function foo($param1, $param2) {
	echo "function foo is called, all went fine...\n";
}

// calling the function and passing _3_ parameters
foo(1, 2, 3);
?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-25 17:02 UTC] nicos@php.net
Reproduced with 4.3.2RC4 and PHP5. 

I'm not sure if its a feature request or if its a bug but its true that IMHO, it should raise an E_WARNING as  ZEND_WRONG_PARAM_COUNT(); or at least an E_NOTICE.
 [2003-05-25 17:22 UTC] b_ulrich at t-online dot de
I think this isn't a bug and there should be no warning.

Reason:
Users can define functions of variable number of parameters.
So you can define a function with no parameters like 
function foo() { ...} and cal it with a different number of parameters like foo($a,$b); foo($a,$b,$c,$d);

To handle them ther are functions like func_num_arg() or func_get_args()

So warnings are wrong in that case.
 [2003-05-25 17:32 UTC] meebey@php.net
I didn't say anything about calling an user function with a variable parameter list, that is a completely different situation.
 [2003-05-25 21:30 UTC] sniper@php.net
There's nothing to fix here, more is broken if some error is added..

 [2003-05-26 04:08 UTC] meebey@php.net
if not error than at least a warning... It's very confusing when APIs in PHP programs change and after searching for hours, the problem is found which is a function call with too much parameters. I always exspected that PHP will give a warning like I get them with the C functions.
Also it's bad programming, ignoring this kind of error is not good.
 [2003-05-26 04:11 UTC] derick@php.net
This can not be implemented because:
1. it breaks BC
2. it renders func_get_args() totally useles.

no warning, no nothing; it's fine as-is
 [2003-05-26 04:22 UTC] meebey@php.net
I agree with the BC....
what about doing this in ZE2 then?
 [2003-05-26 04:30 UTC] derick@php.net
There is no *good* reason to do it, only two reasons *not* to do it. Why break BC with PHP 5 if you don't have to?
 [2003-05-26 13:30 UTC] meebey@php.net
but this change, which could be an option in php.ini strict_function_overload = (on|off) would allow cleaner programming...  overloading with foo(...) should be of course still possible and the paremters accessed through func_get_args().
 [2003-05-26 13:34 UTC] derick@php.net
No, this would make scripts less portable across machines. There is nothing wrong with the current behavior.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Tue Jul 01 10:01:35 2025 UTC