gzread() and gzwrite() have effectively a 4GiB limit at the moment
because the APIs of the zlib library use unsigned ints.
For example, this means that the count argument of gzread() and gzwrite()
& co effectively are modulo 2**32.
Fix this by adding a loop to handle all bytes.
As for automated testing, I didn't find an easy way to write a phpt for
this that wouldn't use a lot of memory or requires a large file.
For instance, the gzread() test that I manually ran requires a 4MiB
input file (and I can't shrink it because zlib has a max window size).
Here are the testing instructions, run on 64-bit:
To test for gzwrite():
```php
$f = gzopen("out.txt.gz", "w");
gzwrite($f, str_repeat('a', 4*1024*1024*1024+64)); // 4GiB + 64 bytes
```
Then use `zcat out.txt.gz|wc -c` to check that all bytes were written
(should be 4294967360).
To test for gzread():
Create a file containing all a's for example that is 4GiB + 64 bytes.
Then compress it into out.txt.gz using the gzip command.
Then run:
```php
$f = gzopen("out.txt.gz", "r");
$str = gzread($f, 4*1024*1024*1024+64);
var_dump(strlen($str)); // 4294967360
var_dump(substr($str, -3)); // string (3) "aaa"
```
Closes GH-17775.
zlib_create_dictionary_string() allocates memory, so we can leak memory
if there's an early exit before the assignment to the return value.
Solve this by moving all validation upwards.
Closes GH-17788.
Because of the "H" modifier in ZPP, there are two bugs:
1) The stub is wrong and will cause a crash in debug mode.
2) Non-dynamic properties are not read correctly because they are not
DEINDIRECTed.
Closes GH-17750.
We must not `efree()` `zend_string`s, since they may have a refcount
greater than one, and may even be interned.
We also must not confuse `zend_string *` with `zend_string **`.
And we should play it safe by using `safe_emalloc()` to avoid
theoretical integer overflows.
We also simplify a bit, according to suggestions of @TimWolla.
Closes GH-16335.
Cirrus will no longer offer unlimited free builds starting next month. We don't
have an alternative for FreeBSD and ARM, so move what we can for now.
Closes GH-11898
The length of "output_handler" is supposed to be passed, but as sizeof
is used, the resulting number includes the NUL character, so the length
is off-by-one. Subtract one to pass the correct length.
Closes GH-10667.
This reverts commit 94ee4f9834.
The commit was a bit too late to be included in PHP 8.2 RC1. Given it's a massive ABI break, we decide to postpone the change to PHP 8.3.
Using php_info_print_table_header() for "Foo: bar" looks odd and out of place,
because the whole line is colored. It is also questionable from a HTML
semantics point of view, because it does not described the columns that follow.
The use of this across extensions is inconsistent. It was part of the skeleton,
but ext/date or ext/json already use a regular row.
Drop period in error messages
2 reasons:
- These error messages are not regular sentences.
- Having the offending value between parenthesis after the period looks weird.
Closes GH-8858.
Add zend_ini_parse_quantity() and deprecate zend_atol(), zend_atoi()
zend_atol() and zend_atoi() don't just do number parsing.
They also check for a 'K', 'M', or 'G' at the end of the string,
and multiply the parsed value out accordingly.
Unfortunately, they ignore any other non-numerics between the
numeric component and the last character in the string.
This means that numbers such as the following are both valid
and non-intuitive in their final output.
* "123KMG" is interpreted as "123G" -> 132070244352
* "123G " is interpreted as "123 " -> 123
* "123GB" is interpreted as "123B" -> 123
* "123 I like tacos." is also interpreted as "123." -> 123
Currently, in php-src these functions are used only for parsing ini values.
In this change we deprecate zend_atol(), zend_atoi(), and introduce a new
function with the same behavior, but with the ability to report invalid inputs
to the caller. The function's name also makes the behavior less unexpected:
zend_ini_parse_quantity().
Co-authored-by: Sara Golemon <pollita@php.net>
The fix for GH-7953 introduced a regression by being to deliberate
adding the respective headers. These must only be added, if the
handler starts, but is not finalizing.
Closes GH-8353.
If an output handler has not yet been started, calling `ob_clean()`
causes it to start. If that happens, we must not forget to set the
`Content-Encoding` and `Vary` headers.
Closes GH-7960.
On x86_64 glibc memrchr() uses SSE/AVX CPU extensions and works much
faster then naive loop. On x86 32-bit we still use inlined version.
memrchr() is a GNU extension. Its prototype becomes available when
<string.h> is included with defined _GNU_SOURCE macro. Previously, we
defined it in "php_config.h", but some sources may include <string.h>
befire it. To avod mess we also pass -D_GNU_SOURCE to C compiler.
It's the same as (int) zend_atol() -- it doesn't try to do anything
integer size specific. Canonicalize to one function in preparation
for renaming zend_atol() to something less misleading.
FFI test is adjusted to use a zend_test function. It just calls
zend_atol() internally, but could really be anything.
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
