DEC2BIN() and HEX2BIN(): support of more than 10 binary digits, like BASE() do. While 10 digit are enough for decimal and hex numbers, 10 bit are very few for a binary number. Consider that as two's complement representation, the range is restricted to -512 / +511 only. On the other side, as now BASE() do not support negative numbers, so there is no solution to represent high negative numbers. Binary numbers should be supported up to 32 or 64 bit for DEC2BIN() and HEX2BIN(), while BASE() should support negative binary numbers. I saw that OpenDocument Formula require 10 digit, but let implement more than 10 digit (say "implementation-defined"): http://docs.oasis-open.org/office/v1.2/cd05/OpenDocument-v1.2-cd05-part2.html#a_6_19_7_DEC2BIN http://docs.oasis-open.org/office/v1.2/cd05/OpenDocument-v1.2-cd05-part2.html#a_6_19_11_HEX2BIN

for BASE() I opened https://bugs.freedesktop.org/show_bug.cgi?id=45951

We can make optional the second parameter for the number of digit (or the position of binary sign) like BASE() 3th parameter. If this parameter is missing, default to 10 for backward compatibility. The parameter should support up to 64 bit

Thanks for new idea in 3.5.1 dec2bin writes Err502 if argument is more than 511, and if 511 then produces 9 digits. Therefore not implemented yet.

DEC2BIN() accept up to 10 as second argument and support two's complement representation, so results in range -512/+511 on 10 digits, HEX2BIN() accept up to 10 as second argument but do not support negative numbers, so 9 bits of results and 0 as MSb. Apparentrly there is also another limitation with HEX2BIN() in current implementation: the first argument must have no more than 10 hex digits (40 bit), also when the output would fit in 10 binary digits. For example converting: "0000000001" (10 digits) result 1, but converting "00000000001" (11 digits) results Err:502.

The number of digits is fixed because these functions stem from other existing spreadsheet implementations which is the reason why they are defined as this in OpenFormula. Introducing further parameters or even worse yet another "implementation defined" would have impacts on interoperability. The only proper way would be to implement some new functions with yet to be defined behavior.

*** Bug 93627 has been marked as a duplicate of this bug. ***