The function is supposed to accept only arrays by design.

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

>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.

>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