Noticed this while working on attributes strict_types handling.
We sometimes insert dummy frames internally, but I don't think
these should show up in debug_backtrace output unless they're
needed, either to display an include call or to preserve file/line
information that would otherwise get lost.
Fix #76735: Incorrect message in fopen on invalid mode
We have to log errors in `stream_opener` callbacks to the wrapper's
error log, because otherwise we may pick up an unrelated `errno` or a
most generic message.
Fix #77493: curl_basic_009 fails with newer curl versions
libcurl 7.62.0 introduced a maximum protocol length of 8, so this test
case failed with `CURLE_URL_MALFORMAT`. While this is lifted to 40 as
of libcurl 7.65.0, and this test case has already been fixed with
commit e27301c[1], we restore the original intention to check for a
`CURLE_UNSUPPORTED_PROTOCOL ` error.
Normalize the behavior between the file functions and those on
SplFileObject.
Be consistent about throwing regardless of whether the delimiter etc
is empty or has too many characters. I don't think it's worthwhile
to distinguish these cases.
Back when we looked into this originally, there was some hope that
we might want to add support for multiple-character delimiter etc,
but after a cursory look, I really don't think this is going to
happen (for fputcsv maybe, but for fgetcsv this just makes an already
broken function much more complicated.)
Alex Dowad [Mon, 11 May 2020 18:32:13 +0000 (20:32 +0200)]
SplFixedArray is Aggregate, not Iterable
One strange feature of SplFixedArray was that it could not be used in nested foreach
loops. If one did so, the inner loop would overwrite the iteration state of the outer
loop.
To illustrate:
$spl = SplFixedArray::fromArray([0, 1]);
foreach ($spl as $a) {
foreach ($spl as $b) {
echo "$a $b";
}
}
Would only print two lines:
0 0
0 1
Use the new InternalIterator feature which was introduced in ff19ec2df3 to convert
SplFixedArray to an Aggregate rather than Iterable. As a bonus, we get to trim down
some ugly code! Yay!
If restoring of any not registered built-in wrapper is requested, the
function is supposed to fail with a warning, so we have to check this
condition first.
Furthermore, to be able to detect whether a built-in wrapper has been
changed, it is not sufficient to check whether *any* userland wrapper
has been registered, but rather whether the specific wrapper has been
modified.
Fix #79423: copy command is limited to size of file it can copy
Passing `NULL` as `lpFileSizeHigh` to `GetFileSize()` gives wrong
results for files larger than 0xFFFFFFFF bytes. We fix this by using
`GetFileSizeEx()`, and let the mapping fail, if the file size is too
large for the architecture.
Cross checking implementations from other languages, empty strings
are always allowed. PHP's output is peculiar due to it's insistence
to encode a trailing \0, but otherwise sensible and does round-trip
as expected.
Return "0000" instead of false to have a consistent return type.
"0000" is already a possible return value if the string doesn't
contain any letters, such as with soundex(" "). We can treat the
case of soundex("") exactly the same.
php_unescape_html_entities() never returns null, so this function
can never return false.
php_unescape_html_entities() probably should be failing with OOM
for the "overflow" case, but even if it did, it would not be
signalled through a false return value.
The implementation here was pretty confused. In reality the only
error condition it has right now is that for a string input,
from & length cannot be arrays.
The fact that the array lengths are the same was probably supposed
to be checked for the case of array input, as it wouldn't matter
otherwise.
We missed the change to make this an Error exception in PHP 8,
but at least elevate it to a warning, to avoid a notice -> exception
jump at a later time.
Checking the linker compatibility with extranous `ImageLoad()` calls is
possible, but unnecessary, since the modules are either already loaded
or loaded shortly afterwards, so that we can get the required
information directly from the module handles. And actually, doing
`ImageLoad()` as well as `LoadLibrary()` leaves a tiny room for a race
condition, because both functions will lookup the module in the search
path, so there is no *guarantee* that both are dealing with the same
module. Dropping the `ImageLoad()` calls also has the advantage to no
longer face the issue reported in bug #79557. A very minor additional
advantage is that we no longer have to link against Imagehlp.dll.
Furthermore, there is no need to check for CRT compatibility multiple
times, so we can simplify the signature of `php_win32_crt_compatible`,
and at the same time clean up main.c a bit.
These changes require to change the signature of the exported
`php_win32_image_compatible` and `php_win32_crt_compatible` functions,
which now expect a `HMODULE` and nothing, respectively, instead of the
module name.
Instead of attempting to map large files into memory at once, we map
chunks of at most `PHP_STREAM_MMAP_MAX` bytes, and repeat that until we
hit the point where `php_stream_seek()` fails (see bug 54902), and copy
the rest of the file by reading and writing small chunks.
We also fix the mapping behavior for zero bytes on Windows, which did
not error (as with `mmap()`), but would have mapped the remaining file.
The implementation did not check for PQunescapeBytea failure
correctly, because it checked for a null pointer after estrndup,
which certainly cannot happen. Inspection of the PGunescapeBytea
implementation has shown that this function can only fail on OOM,
so let's check for that explicitly and remove false as a possible
return type.
While we're here, avoid an unnecessary copy of the result.
Due to improvements to early binding, the opcode based check is
no longer accurate. Reuse the syntactic check we're already using
for declares instead.
projects / php / log