This never worked and creates a broken object,
and on master can cause a crash with foreach.
It makes no sense to fix a behaviour that never worked, block it
instead.
Closes GH-19089.
* pdo_odbc: Don't fetch 256 byte blocks for long columns
Fetching 256 byte blocks can confuse some drivers with conversion
routines. That, and it seems to me the round trips to and from a
database could be a major performance impact.
Instead, we try to fetch all at once, and continue fetching if a
driver somehow has more for us.
This has been tested with a problematic case with the Db2i driver
with stateful MBCS encodings.
See GH-10733 for discussion about this and issues it can resolve.
* change to separate by 256 bytes, when C->fetched_len == SQL_NO_TOTAL
change to separate by 256 bytes, when C->fetched_len == SQL_NO_TOTAL
changed from 256 byte to 2048 byte buf block.
* Make long column buffer size single define
Could be configurable maybe, but best to avoid magic numbers even for a
compile-time constant.
* Use ZendMM page size minus zend_string overhead
Change recommended by Christoph.
Probably a little better performance wise I have to guess.
* [skip ci] Update comment to mention constant
* Update UPGRADING for PDO_ODBC change
mention GH issues in UPGRADING too
* Update NEWS for PDO_ODBC change
---------
Co-authored-by: SakiTakamachi <saki@sakiot.com>
Instead of using lookup tables, we can use a combination of shifts and
byte swapping to achieve the same thing in less cycles and with less
code.
Benchmark files
---------------
pack1.php:
```php
for ($i = 0; $i < 10_000_000; ++$i) {
pack("J", 0x7FFFFFFFFFFFFFFF);
}
```
pack2.php:
```php
for ($i = 0; $i < 4000000; ++$i) {
pack("nvc*", 0x1234, 0x5678, 65, 66);
}
```
On an i7-4790:
```
Benchmark 1: ./sapi/cli/php pack1.php
Time (mean ± σ): 408.8 ms ± 3.4 ms [User: 406.1 ms, System: 1.6 ms]
Range (min … max): 403.6 ms … 413.6 ms 10 runs
Benchmark 2: ./sapi/cli/php_old pack1.php
Time (mean ± σ): 451.7 ms ± 7.7 ms [User: 448.5 ms, System: 2.0 ms]
Range (min … max): 442.8 ms … 461.2 ms 10 runs
Summary
./sapi/cli/php pack1.php ran
1.11 ± 0.02 times faster than ./sapi/cli/php_old pack1.php
Benchmark 1: ./sapi/cli/php pack2.php
Time (mean ± σ): 239.3 ms ± 6.0 ms [User: 236.2 ms, System: 2.3 ms]
Range (min … max): 233.2 ms … 256.8 ms 12 runs
Benchmark 2: ./sapi/cli/php_old pack2.php
Time (mean ± σ): 271.9 ms ± 3.3 ms [User: 269.7 ms, System: 1.3 ms]
Range (min … max): 267.4 ms … 279.0 ms 11 runs
Summary
./sapi/cli/php pack2.php ran
1.14 ± 0.03 times faster than ./sapi/cli/php_old pack2.php
```
On an i7-1185G7:
```
Benchmark 1: ./sapi/cli/php pack1.php
Time (mean ± σ): 263.7 ms ± 1.8 ms [User: 262.6 ms, System: 0.9 ms]
Range (min … max): 261.5 ms … 268.2 ms 11 runs
Benchmark 2: ./sapi/cli/php_old pack1.php
Time (mean ± σ): 303.3 ms ± 6.5 ms [User: 300.7 ms, System: 2.3 ms]
Range (min … max): 297.4 ms … 318.1 ms 10 runs
Summary
./sapi/cli/php pack1.php ran
1.15 ± 0.03 times faster than ./sapi/cli/php_old pack1.php
Benchmark 1: ./sapi/cli/php pack2.php
Time (mean ± σ): 156.7 ms ± 2.9 ms [User: 154.7 ms, System: 1.7 ms]
Range (min … max): 151.6 ms … 164.7 ms 19 runs
Benchmark 2: ./sapi/cli/php_old pack2.php
Time (mean ± σ): 174.6 ms ± 3.3 ms [User: 171.9 ms, System: 2.3 ms]
Range (min … max): 170.7 ms … 180.4 ms 17 runs
Summary
./sapi/cli/php pack2.php ran
1.11 ± 0.03 times faster than ./sapi/cli/php_old pack2.php
```
Closes GH-18524.
Co-authored-by: divinity76 <divinity76@gmail.com>
Have each of the specialized methods for registering a constant return a
pointer to the registered constant the same way that the generic
`zend_register_constant()` function does, and use those in the generated
arginfo files to avoid needing to search for a constant that was just
registered in order to add attributes to it.
Since `ZSTR_LEN()` returns a `size_t` (unsigned integer), the value can only be either "not equal to 0" or "equal to 0". The third `else` branch was unreachable, making the `*handled_output = NULL;` assignment dead code.
The `defaultMemoryManager` is only available via a non-public
header and is not supposed to be used by users of the library [1].
It also has a very generic name, further indicating that it is not
supposed to be used.
Instead pass the memory manager explicitly, which is how the library is
supposed to be used.
[1] https://github.com/uriparser/uriparser/issues/52#issuecomment-453853700
There are two bugfixes here.
The first was a crash that I discovered while working on GH-19035.
The check for when a file pointer was still occupied was wrong, leading
to a UAF. Strangely, zip got this right.
The second issue was that even after fixing the first one, the file
contents were garbage. This is because the file write offset for the
phar stream was wrong.
Closes GH-19038.
The copy function does two things wrong:
- The error recovery logic is a hack that temporarily moves the fp
pointer to cfp, even though it's not compressed. The respective error
recovery it talks about is not present in the code, nor is it
necessary. This is the direct cause of the double free in the original
reproducer. Fixing this makes it crash in another location though.
- The link following logic is inconsistent and illogical. It cannot be a
link at this point.
The root cause, after fixing the above issues, is that the file pointers
are not reset properly for the copy. The file pointer need to be the
original ones to perform the copy from the right source, but after that
they need to be set properly to NULL (because fp_type == PHAR_FP).
Closes GH-19035.
Co-authored-by: Yun Dou <dixyes@gmail.com>
Relates to #14461 and https://wiki.php.net/rfc/url_parsing_api
Co-authored-by: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
Co-authored-by: Tim Düsterhus <tim@tideways-gmbh.com>
