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!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.