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