We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
Historically, the _ex variants separated the zval first, if a
conversion was necessary. This distinction no longer makes sense
since PHP 7.
The only difference that was still left is that _ex checked whether
the type is the same first, but the usage of these macros did not
actually distinguish on whether such an inlined check is valuable
or not in a given context.
Also drop the unused convert_to_explicit_type macros.
Disallows constructing an `IMAPConnection` class directly with `new IMAPConnection` construct, by throwing an `Error` exception if attempted.
`imap_open` is still the only way to create `IMAPConnection` objects.
Fills out the array/object-property insert helpers for zend_array, zend_object, and zend_reference.
This adds the following matrix of 18 APIs
add_next_index_T()
add_index_T()
add_assoc_T()
add_assoc_T_ex()
add_property_T()
add_property_T_ex()
Where T in array, object, reference
Converted internal callsites currently doing an explicit object wrap.
* PHP-8.0:
Fix Bug #80438: imap_msgno() incorrectly warns and return false on valid UIDs in PHP 8.0.0
Rename XmlParser to XMLParser for consistency with XMLWriter/XMLReader
Checking for a valid Unique ID (UID) cannot use the convenience macro as they might
be larger than the message number which has for maximum value the total number of
current messages available in the mailbox.
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.
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.
At least on Windows, some static variables are lazily initialized
during `mail_open()` and `mail_lsub()`, which are reported as memory
leaks. We suppress these false positives.
Closes GH-6326.
These are typical boolean parameters, so we shouldn't advertize them as
integers. For the `$reverse` parameter that even fixes expectations,
because the `reverse` member is a bitfield of 1 bit, so assigning any
even integer would not set it.
Closes GH-6328.
