[DISCUSSION] bcmath: adding bcgetopts() and bcsetopts() to get or set bcmath options

php.internals

Quake MMO

1 year ago
Hello all, Would adding a bcgetopts(): int and a bcsetopts(int $opts): void calls be useful? At this time there's no way to influence bcmath's behavior other than bcscale(). An example of option that could be configurable through this mechanism would be automatic removal of trailing / leading zeros in the results returned by bcmath. bcscale(10); echo bcadd('1', '2'); result: 3.0000000  If we could tell bcmath to strip the trailing zeros by calling bcsetopts(bcgetopts() | BC_STRIP_TRAILING_ZEROS)); , the result should be just '3'. Some options I could think of: BC_STRIP_TRAILING_ZEROS BC_STRIP_LEADING_ZEROS BC_STRIP_ZERO_INTEGER (so instead of returning 0.5, it would just return .5) The actual code to strip the trailing/leading zeros seems to already be in the library, just not exposed to the API (bc_rm_*() in libbcmath/src/rmzero.c). I'm using PHP's bcmath extensively in a performance-sensitive application and sanitizing the results in PHP is a performance sink that could be avoided this way. Thank you for your attention.

Ayesh - PHP.Watch

1 year ago
> Would adding a bcgetopts(): int and a bcsetopts(int $opts): void calls > be useful? > > At this time there's no way to influence bcmath's behavior other than > bcscale(). >
How about adding these as methods/properties to the `BcMath\Number` class? `BcMath\Number` does not use the `bcmath.scale` INI directive, and in my opinion, it is the correct way to do it. Everything that affects the operations are just there in the code, and there is no hidden global state.

Quake MMO

1 year ago
On 7/16/25 13:56, Ayesh Karunaratne wrote:
>> Would adding a bcgetopts(): int and a bcsetopts(int $opts): void calls >> be useful? >> >> At this time there's no way to influence bcmath's behavior other than >> bcscale(). >> > How about adding these as methods/properties to the `BcMath\Number` class? > > `BcMath\Number` does not use the `bcmath.scale` INI directive, and in > my opinion, it is the correct way to do it. Everything that affects > the operations are just there in the code, and there is no hidden > global state.
That would also totally work. Anything that would allow sanitizing the string directly in the extension as opposed to doing it in PHP would be a great progress. I would vouch for the sanitization switch to be a global state setting such as the bcscale, as opposed to (only) be a callable method/function. This way, we would avoid an extra call from PHP for sanitization.