On 26.04.2019 at 09:45, Benjamin Morel wrote: >> I don't really understand it, I must be strict, converting to zero >> will lead to wrong calculations. > > That's what I said :) Fully agree here, any non-numeric string should throw > an exception. > > In summary, I would check that the string matches ` > /^[\+\-]?[0-9]+(\.[0-9]+)?$/`or else throw an exception.
Throwing an exception would be rather uncommon for functions, and would definitely have to wait for PHP 8 for BC reasons. Another option might be to introduce an object-oriented layer on top of libbcmath. A basic problem of the BC extension is that all functions accept strings, convert these to bc_nums[1], do the actual calculation, convert the bc_nums back to strings[2], and return these. This looks like quite some overhead, especially for more complex calculations where the intermediary results are not even needed as strings. If there is an OOP API, the conversion from string would only be needed in the constructor, and conversion to string only in the __toString() method. All intermediary calculations wouldn't need the from/to string conversions. And of course, users could switch to the OOP API if they desire, but could stick with the procedural API otherwise. An additional benefit might be that we sometime could switch away from the decimal storage[3] which appears to be mostly useful for the string conversions, but is otherwise wasteful (1 byte per decimal digit). [1] <https://github.com/php/php-src/blob/php-7.3.4/ext/bcmath/libbcmath/src/str2num.c#L44> [2] <https://github.com/php/php-src/blob/php-7.3.4/ext/bcmath/libbcmath/src/num2str.c> [3] <https://github.com/php/php-src/blob/php-7.3.4/ext/bcmath/libbcmath/src/bcmath.h#L61-L64> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
