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.
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.
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.