Bug #40793 [Com]: xmlrpc_is_fault shows warning if parameter is not an array

From: Date: Thu, 21 Jul 2016 09:56:20 +0000
Subject: Bug #40793 [Com]: xmlrpc_is_fault shows warning if parameter is not an array
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-202469@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=40793&edit=1 ID: 40793 Comment by: josef dot sabl at gmail dot com Reported by: camka at email dot ee Summary: xmlrpc_is_fault shows warning if parameter is not an array Status: Not a bug Type: Bug Package: XMLRPC-EPI related Operating System: windows PHP Version: 5.2.1 Block user comment: N Private report: N New Comment: >The function is supposed to accept only arrays by design. Than it is designed horribly and everybody, just everybody, needs to implement their own method (congrats!). And also example in documentation of xmlrpc_encode_request function (which xmlrpc_is_fault points to) should be fixed because it is like this: if ($response && xmlrpc_is_fault($response)) { trigger_error("xmlrpc: $response[faultString] ($response[faultCode])"); } else { print_r($response); } And first line just throws error for some $responses. >Actually we have simular things in many places Yes, PHP has many poorly designed functions. At least we agree on something :-D Previous Comments: ------------------------------------------------------------------------ [2007-03-13 13:56:25] tony2001@php.net >Sory, but I slightly disagree. It's hard to disagree with a fact. The function IS designed this way and is_array() check is not that ugly, dirty, unclear and confusing. Whether it was reasonable implementation or not - that's a different question. The XMLRPC extension is unmaintained for a long time and I personally do not feel willing enough to change it's behavior just because it requires one is_array() call. And this is definitely not a BUG, but a change request. Actually we have simular things in many places - for example, fread() and fwrite() emit a notice when invalid stream passed, even though fopen() might return FALSE. And you have to use those "unnecessary, confusing, ugly, dirty and unclear" checks to be sure the stream is valid. ------------------------------------------------------------------------ [2007-03-13 13:41:04] camka at email dot ee Sory, but I slightly disagree. In current implementation I must implicitly check, if decoded xml response is array or not before passing it to xmlrpc_is_fault(), otherwise it gives me a notice. This is just unnecessary additional confusing check to do, which makes a code dirty and unclear. If this check would be inside is_fault function the implementation would be more incapsulated and simple for developer using xmlrpc ext. Or may be there is another way to check whether the response contains a fault or not? thank you ------------------------------------------------------------------------ [2007-03-13 12:51:54] tony2001@php.net The function is supposed to accept only arrays by design. ------------------------------------------------------------------------ [2007-03-13 12:41:37] camka at email dot ee Description: ------------ xmlrpc_is_fault is supposed to accept a result returned by xmlrpc_decode. As xmlrpc_decode can return non-array value, xmlrpc_is_fault throws a notice: xmlrpc_is_fault() : Array argument expected which is incorrect, as it is common to simply pass the decoded xml response directly into is_fault() function to check, whether it has been fault or not. Reproduce code: --------------- <? var_dump(xmlrpc_is_fault(xmlrpc_decode('<?xml version="1.0" encoding="utf-8"?><methodResponse><params><param><value><int>2</int></value></param></params></methodResponse>', 'utf-8'))); Expected result: ---------------- bool(false) Actual result: -------------- Notice: PHPDocument8 line 2 - xmlrpc_is_fault() [function.xmlrpc-is-fault]: Array argument expected bool(false) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=40793&edit=1

« previous php.bugs (#202469) next »