Also avoid some memsets where we do call bc_new_num.
After:
```
1.2066178321838
1.5389559268951
1.6050860881805
```
Before:
```
1.3858470916748
1.6806011199951
1.9091980457306
```
Using SIMD to accelerate the validation.
Using the benchmark from #14076.
After:
```
1.3504369258881
1.6206321716309
1.6845638751984
```
Before:
```
1.4750170707703
1.9039781093597
1.9632289409637
```
Since freeing can deal with NULL, we can avoid calling bc_init_num and
avoid resetting the number during parsing.
Using benchmark from #14076.
Before:
```
1.544440984726
2.0288550853729
2.092139005661
```
After:
```
1.5324399471283
1.9081380367279
2.065819978714
```
On my i7-4790 with benchmark from #14076, on top of #14101 I obtain the
following results:
before (with #14101):
```
1.672737121582
2.3618471622467
2.3474779129028
```
after (with #14101 + this):
```
1.5878579616547
2.0568618774414
2.0204811096191
```
Since the two allocations are tied together anyway, we can just use a
single allocation. Moreover, this actually seemed like the intention
because the bc_struct allocation already accounted for the length and
scale.
power is a copy of base and returns early if base->n_scale is non-zero. Since
scale is size_t, it is always greater than or equal to 0, so rscale is always
the value of scale.
Re-formats the BCmath extension to have consistent formatting.
Mostly, it adds the spaces in calculations to have them more readable.
Also:
- removes unused headers
- removes few variables which are used only once in the code
Co-authored-by: George Peter Banyard <girgias@php.net>
* ext/bcmath: coding style: use indentation
And add braces to block statements, as the current code was pretty much unreadable with how inconsistent it was.
* ext/bcmath: Remove some useless header inclusions
* ext/bcmath: Use standard C99 bool type instead of char
* ext/bcmath: Include specific headers instead of config.h
* Restructure definitions to reduce header inclusions
* Use size_t as a more appropriate type
* Remove unused variable full_scale
* Refactor bc_raisemod() to get rid of Zend dependencies
This separates the concerns of throwing exceptions back into the PHP_FUNCTION instead of being the responsibility of the library
* Refactor bc_raise() to get rid of Zend dependencies
This separates the concerns of throwing exceptions back into the PHP_FUNCTION instead of being the responsibility of the library
* Refactor bc_divmod() and bc_modulo() to return bool
Return false on division by 0 attempt instead of -1 and true on success instead of 0
* Refactor bc_divide() to return bool
Return false on division by 0 attempt instead of -1 and true on success instead of 0
* Zend/zend_enum: make `forbidden_methods` static+const
* main/php_syslog: make `xdigits` static
* sapi/fpm: make several globals `const`
* sapi/phpdbg: make `OPTIONS` static
* sapi/phpdbg/help: make help texts const
* sapi/cli: make `template_map` const
* ext/ffi: make `zend_ffi_types` static
* ext/bcmath: make `ref_str` const
* ext/phar: make several globals static+const
* PHP-7.3:
Fixed bug #78910Fix#78878: Buffer underflow in bc_shift_addsub
Fix test
Fix#78862: link() silently truncates after a null byte on Windows
Fix#78863: DirectoryIterator class silently truncates after a null byte
Fix#78943: mail() may release string with refcount==1 twice
* PHP-7.2:
Fixed bug #78910Fix#78878: Buffer underflow in bc_shift_addsub
Fix test
Fix#78862: link() silently truncates after a null byte on Windows
Fix#78863: DirectoryIterator class silently truncates after a null byte
- More common filename accross the PHP repository
- Additionally, this patch replaces some legacy form feed (FF or ^L)
characters (for printers) to LF (\n) newline character.
By avoiding integer overflow in the implementation entirely. The
multiplication was already explicitly checked for overflow, so also
add a check for the addition and remove the overflow checks after
the calculation.
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
Gina Peter Banyard