7.3.26 is next

Fixed bug #80310: Support for icu4c 68.1.

On stable versions, bring back the TRUE/FALSE defines by defining
_U_DEFINE_TRUE_AND_FALSE.

Closes GH-6397.

Fix #80266: parse_url silently drops port number 0

As of commit 81b2f3e[1], `parse_url()` accepts URLs with a zero port,
but does not report that port, what is wrong in hindsight.

Fix #80266: parse_url silently drops port number 0

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.

show more ...

Fix another implicit function declaration in configure

As mentioned on bug #80171. This one is in libtool.m4, might get
lost on libtool updates.

Fix #70461: disable md5 code when it is not supported in net-snmp

Patch contributed by Alexander Bergmann.

Closes GH-6389.

Fix format specifier

In this function, `i` is of type `size_t`.

Fix #44618: Fetching may rely on uninitialized data

Unless `SQLGetData()` returns `SQL_SUCCESS` or `SQL_SUCCESS_WITH_INFO`,
the `StrLen_or_IndPtr` output argument is not guaranteed to be

Fix #44618: Fetching may rely on uninitialized data

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.

show more ...

Deny cloning of fileinfo objects

Using a cloned finfo object will crash.

Revert "Fix out-of-bounds write"

This reverts commit bf6873a18e3b6b00f82a645c0893a281ae8eadb8.

CVE-2020-26159 is bogus; the "bug" was apparently a false positive
reported by Cov

Revert "Fix out-of-bounds write"

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.

show more ...

Fix #80268: loadHTML() truncates at NUL bytes

libxml2 has no particular issues parsing HTML strings with NUL bytes;
these just cause truncation of the current text content, but parsing

Fix #80268: loadHTML() truncates at NUL bytes

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.

show more ...

Declare may_retry_reparse_point on windows only

Fix #62474: com_event_sink crashes on certain arguments

We have to make sure that the variant is of type `VT_DISPATCH` before
we access it as such.

Closes GH-6372.

Fix #80258: Windows Deduplication Enabled, randon permission errors

A recent bug fix regarding symlinks claimed:

> After resolving reparse points, the path still may be a reparse

Fix #80258: Windows Deduplication Enabled, randon permission errors

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.

show more ...

Fix #80280: ADD_EXTENSION_DEP() fails for ext/standard and ext/date

`ADD_EXTENSION_DEP()` relies on the `PHP_<extname>` config variables to
be set to `"yes"`, and since the standard and

Fix #80280: ADD_EXTENSION_DEP() fails for ext/standard and ext/date

`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.

show more ...

Fix bug 76618

Apply patch which was attached to the bug in July 2018

Don't crash on uninitialized tidy object

"Uninitialized" here means that the object was created ordinarily
-- no constructor skipping involved. Most tidy methods seem to
handle this

Don't crash on uninitialized tidy object

"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.

show more ...

Updated to version 2020.4 (2020d)

Fix #80242: imap_mail_compose() segfaults for multipart with rfc822

libc-client expects `TYPEMESSAGE` with an explicit subtype of `RFC822`
to have a `nested.msg` (otherwise there will be

Fix #80242: imap_mail_compose() segfaults for multipart with rfc822

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.

show more ...

Add char* cast to avoid compiler warnings

In libc-client 2007f `data` is declared as `unsigned char *`; there may
be variants which declare it as `void *`, but in any case picky
comp

Add char* cast to avoid compiler warnings

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.

show more ...

Properly fix #80220

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.

Properly fix #80220

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.

show more ...

Updated to version 2020.3 (2020c)

Fix broken fix for #80239

No idea why that `git am` failed that badly.

Fix #80239: imap_rfc822_write_address() leaks memory

We have to free the address when we're finished with it.

Fix leak in gmp_export()

Fix #64076: imap_sort() does not return FALSE on failure

If unsupported `$search_criteria` are passed to `imap_sort()`, the
function returns an empty array, but there is also an error on

Fix #64076: imap_sort() does not return FALSE on failure

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.

show more ...