| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
On stable versions, bring back the TRUE/FALSE defines by defining
_U_DEFINE_TRUE_AND_FALSE.
Closes GH-6397.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of commit 81b2f3e[1], `parse_url()` accepts URLs with a zero port,
but does not report that port, what is wrong in hindsight.
Since the port number is stored as `unsigned short` there is no way to
distinguish between port zero and no port. For BC reasons, we thus
introduce `parse_url_ex2()` which accepts an output parameter that
allows that distinction, and use the new function to fix the behavior.
The introduction of `parse_url_ex2()` has been suggested by Nikita.
[1] <http://git.php.net/?p=php-src.git;a=commit;h=81b2f3e5d9fcdffd87a4fcd12bd8c708a97091e1>
Closes GH-6399.
|
| |
|
|
|
| |
As mentioned on bug #80171. This one is in libtool.m4, might get
lost on libtool updates.
|
| |
|
|
|
|
| |
Patch contributed by Alexander Bergmann.
Closes GH-6389.
|
| |
|
|
| |
In this function, `i` is of type `size_t`.
|
| |
|
|
|
|
|
|
|
| |
Unless `SQLGetData()` returns `SQL_SUCCESS` or `SQL_SUCCESS_WITH_INFO`,
the `StrLen_or_IndPtr` output argument is not guaranteed to be properly
set. Thus we handle retrieval failure other than `SQL_ERROR` by
yielding `false` for those column values and raising a warning.
Closes GH-6281.
|
| |
|
|
| |
Using a cloned finfo object will crash.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit bf6873a18e3b6b00f82a645c0893a281ae8eadb8.
CVE-2020-26159 is bogus; the "bug" was apparently a false positive
reported by Coverity, and the "fix" apparently wrong, see
<https://github.com/kkos/oniguruma/issues/221>.
Closes GH-6357.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
libxml2 has no particular issues parsing HTML strings with NUL bytes;
these just cause truncation of the current text content, but parsing
continues generally. Since `::loadHTMLFile()` already supports NUL
bytes, `::loadHTML()` should as well.
Note that this is different from XML, which does not allow any NUL
bytes.
Closes GH-6368.
|
| | |
|
| |
|
|
|
|
|
| |
We have to make sure that the variant is of type `VT_DISPATCH` before
we access it as such.
Closes GH-6372.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent bug fix regarding symlinks claimed:
> After resolving reparse points, the path still may be a reparse
> point; in that case we have to resolve that reparse point as well.
While that is basically correct, some reparse points may point to
inaccessible system folders (e.g. `IO_REPARSE_TAG_DEDUP` points to
"\System Volume Information"). Since we don't know details about
arbitrary reparse points, and are mainly interested in nested symlinks,
we take a step back, and only resolve `IO_REPARSE_TAG_SYMLINK` for now.
Close GH-6354.
|
| |
|
|
|
|
|
|
| |
`ADD_EXTENSION_DEP()` relies on the `PHP_<extname>` config variables to
be set to `"yes"`, and since the standard and date extension are always
enabled, we define the respective variables uncoditionally.
Closes GH-6383.
|
| |
|
|
| |
Apply patch which was attached to the bug in July 2018
|
| |
|
|
|
|
| |
"Uninitialized" here means that the object was created ordinarily
-- no constructor skipping involved. Most tidy methods seem to
handle this fine, but these three need to be guarded.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
libc-client expects `TYPEMESSAGE` with an explicit subtype of `RFC822`
to have a `nested.msg` (otherwise there will be a segfault during
free), but not to have any `contents.text.data` (this will leak
otherwise).
Closes GH-6345.
|
| |
|
|
|
|
|
|
| |
In libc-client 2007f `data` is declared as `unsigned char *`; there may
be variants which declare it as `void *`, but in any case picky
compilers may warn about a pointer type mismatch in the conditional
(and error with `-W-error`), so we're adding a `char *` cast for good
measure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original fix for that bug[1] broke the formerly working composition
of message/rfc822 messages, which results in a segfault when freeing
the message body now. While `imap_mail_compose()` does not really
support composition of meaningful message/rfc822 messages (although
libc-client appears to support that), some code may still use this to
compose partial messages, and using string manipulation to create the
final message.
The point is that libc-client expects `TYPEMESSAGE` with an explicit
subtype of `RFC822` to have a `nested.msg` (otherwise there will be a
segfault during free), but not to have any `contents.text.data` (this
will leak otherwise).
[1] <http://git.php.net/?p=php-src.git;a=commit;h=0d022ddf03c5fabaaa22e486d1e4a367ed9170a7>
Closes GH-6343.
|
| | |
|
| |
|
|
| |
No idea why that `git am` failed that badly.
|
| |
|
|
| |
We have to free the address when we're finished with it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If unsupported `$search_criteria` are passed to `imap_sort()`, the
function returns an empty array, but there is also an error on the
libc-client error stack ("Unknown search criterion: UNSUPPORTED
(errflg=2)"). If, on the other hand, unsupported `$criteria` or
unsupported `$flags` are passed, the function returns `false`. We
solve this inconsistency by returning `false` for unsupported
`$search_criteria` as well.
Closes GH-6332.
|
| | |
|
| |
|
|
|
|
| |
We need to free what we have allocated.
Closes GH-6327.
|
| |
|
|
|
|
|
| |
We need to check whether the given `type`s and `encoding`s are within
bounds to avoid segfaults and out-of-bound reads.
Closes GH-6323.
|
| |
|
|
|
|
| |
We have to clean up even on failure.
Closes GH-6322.
|
| |
|
|
|
|
|
|
|
| |
Unless `topbod` is of `TYPEMULTIPART`, `mail_free_body()` does not free
the `nested.part`; while we could do this ourselves, instead we just
ignore additional bodies in this case, i.e. we don't attach them in the
first place.
Closes GH-6321.
|
| |
|
|
|
|
|
| |
While the zvals may be different, they may still point to the
same array.
Fixes oss-fuzz #26245.
|
| |
|
|
|
|
|
|
| |
If the RHS has INDIRECT elements, we do not those to be added to
the LHS verbatim. As we're using UPDATE_INDIRECT, we might even
create a nested INDIRECT that way.
This is a side-quest of oss-fuzz #26245.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We separate the input arrays and all sub-arrays to avoid modification
of the passed parameters.
This should be rewritten to use `zend_string`s for the "master" branch.
Closes GH-6316.
|
| |
|
|
|
|
|
| |
We have to cater to non-associative arrays where the key may be `NULL`;
we just skip these elements.
Closes GH-6315.
|
| |
|
|
| |
Closes GH-6291.
|
| |
|
|
|
| |
I was expecting this to get fixed quickly, but it didn't.
XFAIL for now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation of `tidyNode::isHtml()` states that this method
"checks if a node is part of a HTML document". That is, of course,
nonsense, since a tidyNode is "an HTML node in an HTML file, as
detected by tidy."
What this method is actually supposed to do is to check whether a node
is an element (unless it is the root element). This has been broken by
commit d8eeb8e[1], which assumed that `enum TidyNodeType` would
represent flags of a bitmask, what it does not.
[1] <http://git.php.net/?p=php-src.git;a=commit;h=d8eeb8e28673236bca3f066ded75037a5bdf6378>
Closes GH-6290.
|
| |
|
|
|
|
|
|
| |
There is no such thing as the "end of the unix epoch", and if it was,
it would certainly not be 2037-10-11T02:00:00. There is, however,
potential integer overflow which we need to avoid.
Closes GH-6288.
|
| |
|
|
| |
When resetting the result's values, we also have to reset its numcols.
|
| |
|
|
| |
As this is an error with xcode 12, see bug #80171.
|
| |
|
|
|
|
| |
Fixes CVE-2020-26159.
Backported from <https://github.com/kkos/oniguruma/commit/cbe9f8bd9cfc6c3c87a60fbae58fa1a85db59df0>.
|
| |
|
|
| |
When committing I didn't notice that version had been just bumped
|
| |
|
|
| |
in included file).
|
| |\
| |
| |
| |
| | |
* PHP-7.2:
bump version to 7.2.35-dev
|
| | | |
|
