XMLRPC and 64bit integers

The xmlrpc extension currently fails to handle 64bit integers[1], and the resolutions all seem suboptimal. XML-RPC is over 15 years old, and the initial specification omitted support for 64bit integers. Today however, XML-RPC implementations frequently need to exchange 64bit integers. A de facto standard, the <i8> integer has been gaining traction in libraries for several years now. In the interest of improving compatibility with these libraries, I created a pull request[2] adding support for decoding <i8> with the xmlrpc extension. In the process of doing this however I realized that I had introduced a problem with xmlrpc encoding. Firstly, I allowed xmlrpc to output a 64bit integer, which was both a spec violation (<int> can only contain a 32bit integer) and caused a test verifying this limitation to fail[3]. This leads me to a series of possible solutions, none of which are good: 1. We can break the spec, and put 64bit integers into <int>, but this is wrong according to the spec and may break some implementations. 2. We could output <i8> in place of <int> which breaks backwards compatibility and possibly compatibility with older implementations of XML-RPC. 3. We could create an opt-in 64bit mode, but people should not need to opt-in to bug fixes (it sets a bad precedent). 4. We could check the size of every individual integer and output <i8> only when exceeding a 32bit integer, but this adds complexity to the actual encoding process. 5. We could allow the decoding of 64bit integers but not allow encoding. This then introduces an inconsistency between encoding and decoding. I would appreciate feedback on how people would like to see this issue resolved. [1] https://bugs.php.net/bug.php?id=66389 [2] https://github.com/php/php-src/pull/555 [3] https://github.com/php/php-src/blob/master/ext/xmlrpc/tests/bug40576_64bit.phpt#L36