Description: ------------ In version 1.07 of the XML-RPC for C/C++ library, its developers added a 64-bit integer datatype to the library[1]. From what I can gather, i8 is not part of the XML-RPC spec, but an extension introduced by the Apache foundation[2]. I'm not sure if that disqualifies it from stuff PEAR::XML-RPC2 wants to support, but for what it's worth, our Perl counterpart[3] 'supports' it. rTorrent's XML-RPC interface uses this 64bit integer, and if I get a response with i8, PEAR::XML-RPC2 throws an exception with a note about an unknown datatype. I have a patch to add 64-bit integer support. It uses the double's datatype instead of an int because (at least on 32-bit systems), PHP's int is an unsigned 32-bit number, and double goes higher (I don't know how high...but if it's not perfect, it's closer to what I needed). [1] http://xmlrpc-c.sourceforge.net/change.html [2] http://ws.apache.org/xmlrpc/types.html [3] http://search.cpan.org/~giraffed/RPC-Xmlrpc_c-1.02/Value/Value.pm#RPC::Xmlrpc_c::Value-%3EnewI8($)

I just realized that this patch does nothing for native XMLRPCext driver that RPC2 can use. It doesn't look like I can do anything to make xmlrpc_decode() handle i8 short of patching the C code for the extension. It returns null values for all i8s.

I don't mind adding 64bit integer support. However, using doubles to do it is just compounding the error. Even in 64 bit systems, a double will lack precision to handle the integer. In 64 bit systems, PHP's int will be 64 bit. I prefer the future-proof solution of using a regular int to stand in for i8, perhaps using string comparison to find out if a decoded i8 will overflow the native int. I'll look into this later. I'll confirm the feature request now.

This bug has been fixed in SVN. 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 opted to support i8 only on 64bit (or larger) systems. Providing the client/server is running on 64bit systems, i8 behaves just as normal, and is used whenever a native integer larger than 32bits is encoded. On 32bit systems, usage of i8 throws an exception.