Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.14.0

Doc Bug #14337 Better document the limits of hashes
Submitted: 2008-07-12 18:58 UTC
From: doconnor Assigned: yunosh
Status: Closed Package: SOAP (version 0.11.0)
PHP Version: Irrelevant OS:
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 41 + 25 = ?

 
 [2008-07-12 18:58 UTC] doconnor (Daniel O'Connor)
Description: ------------ In SOAP_Base::_isHash() // If someone has a large hash they should really be defining the // type. See Bug #12406 and others. This particular behaviour should be either documented or improved in some fashion - particularly because when people pass in oodles of data, things tend to die when printing out the backtrace (Bug #10897).

Comments

 [2008-07-12 18:58 UTC] doconnor (Daniel O'Connor)
Code: function _isHash(&$a) { // I really dislike having to loop through this in PHP code, really // large arrays will be slow. We need a C function to do this. $it = 0; foreach ($a as $k => $v) { // Checking the type is faster than regexp. if (!is_int($k)) { return true; } // If someone has a large hash they should really be defining the // type. if ($it++ > 10) { $this->_raiseSoapFault('Large associative array passed where a SOAP_Value was expected'); return false; } } return false; }
 [2008-07-15 00:46 UTC] yunosh (Jan Schneider)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. I removed the check completely. I can rarely imagine a real-world hash which is so large that checking more than 10 keys for their type is really an issue.
 [2008-07-16 14:26 UTC] doconnor (Daniel O'Connor)
See also bug #13552