The bindec function has a limited range for the input parameter, which in my view doesn't make sense.
For example: BINDEC(101110) yields 46, but BINDEC(10111110111) yields err:502.
I think you mean BIN2DEC(). As documented here it takes 10 digits (https://help.libreoffice.org/Calc/Add-in_Functions,_List_of_Analysis_Functions_Part_One#BIN2DEC).
This is due to the fact that SCA_MAXPLACES is set to 10 (see http://opengrok.libreoffice.org/xref/core/scaddins/source/analysis/analysis.cxx#SCA_MAXPLACES).
No idea whether we can raise that limit to SAL_MAX_INT32.
BIN2DEC have the same limitation in Excel too.
ODF specifications have also the same limitation.
I don't know why this limit.
You can use DECIMAL function in replacement of (whatever)2DEC which have higher limits or BASE for DEC2(whatever).
(In reply to Philipp Weissenbacher from comment #1)
> I think you mean BIN2DEC(). As documented here it takes 10 digits
> This is due to the fact that SCA_MAXPLACES is set to 10 (see
> No idea whether we can raise that limit to SAL_MAX_INT32.
It sounds like
1) This is a pretty straightforward improvement to the codebase
2) There's no clearcut reason why we wouldn't want to increase the bound
I'll toss it in NEW for now. If a dev has a good explanation about why we can't/shouldn't bother with this one, please feel free to RESOLVE it appropriately.
BIN2DEC() has to have these limitations to be interoperable with Excel, the ODF OpenFormula (ODFF) definition is