php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved. 		Last updated: Sat Apr 20 10:01:28 2024 UTC