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 > (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. 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. Thanks!
BIN2DEC() has to have these limitations to be interoperable with Excel, the ODF OpenFormula (ODFF) definition is https://docs.oasis-open.org/office/OpenDocument/v1.3/cs02/part4-formula/OpenDocument-v1.3-cs02-part4-formula.html#BIN2DEC