Latest release not compatible with PHP 8.4

[mokraemer]

php-imap/BUILD/imap-1.0.2/php_imap.c: In function ‘zif_imap_append’:
php-imap/BUILD/imap-1.0.2/php_imap.c:808:17: error: too many arguments to function ‘php_pcre_match_impl’
808 | php_pcre_match_impl(pce, internal_date, return_value, subpats, global,
| ^~~~~~~~~~~~~~~~~~~
In file included from php-imap/BUILD/imap-1.0.2/php_imap.c:43:
/usr/include/php8.4/ext/pcre/php_pcre.h:52:14: note: declared here
52 | PHPAPI void php_pcre_match_impl(pcre_cache_entry *pce, zend_string *subject_str, zval *return_value,
| ^~~~~~~~~~~~~~~~~~~

Looks like php 8.4 has another signature.

[cmb69]

That should be fixed with 25b62db, but a new release is pending. Maybe @derickr or @remicollet want to roll 1.0.3?

[cmb69]

Oh, and a general note: consider to switch to a userland IMAP library, perhaps https://github.com/barbushin/php-imap.

[mokraemer]

This is for packaging in a distro - maybe needed for some older software...

[cmb69]

As can be seen in https://github.com/php/pecl-mail-imap/actions/runs/10830123860, the main branch should be compatible with PHP 8.4.

[Slamdunk]

Oh, and a general note: consider to switch to a userland IMAP library, perhaps https://github.com/barbushin/php-imap.

I'm sorry, what's the point? That library requires ext-imap: https://github.com/barbushin/php-imap/blob/master/composer.json#L29

[Seldaek]

https://packagist.org/packages/webklex/php-imap implements it in PHP but I'm not sure how good it is, and we use ddeboer/imap which relies on ext-imap anyway so we're also stuck with this. I mean no biggie it's just CI failing the php8.4 builds, nothing urgent.

But I am a bit curious/worried by that statement from @cmb69 - why would you advise we switch?

[cmb69]

why would you advise we switch?

See https://wiki.php.net/rfc/unbundle_imap_pspell_oci8#extimap for the reasoning why this extension has been unbundled.

See also #3 for some ideas that have been discussed prior to unbundling ext/imap.

If there are no field-tested userland libraries available, that would be bad, though.

[Seldaek]

Ok I see, thanks. FWIW https://packagist.org/packages/webklex/php-imap seems decent but per the README not 100% spec compliant and it still relies on ext-imap if available to cover edge cases.

[cmb69]

Hmm, there are also https://github.com/horde/Imap_Client and https://packagist.org/packages/zetacomponents/mail which do not seem to rely on ext-imap, and may still be maintained. Also see https://bugs.php.net/78572#1568965813 – any volunteers?

I'm not sure what to do about ext-imap. Rolling a release is not a real problem, but we need to figure out a plan to gracefully retire it as soon as possible. The c-client code is basically unmaintained for almost 20 years, and I can imagine that there are serious issues for LLP64 data models, and maybe generally 64bit issues. And even ext-imap was in low maintenance for years.

[Seldaek]

Yeah it's one of these old protocols where clients are just stable enough to "just work" but of course other compatibility issues might crop up when we're talking about C code. We use it successfully on ARM64 with PHP 8.3 FWIW.. But we also have a very limited feature scope, and we'll most likely replace it with some S3/SES receiver combo and drop IMAP.

[derickr]

Fixed through 25b62db, so closing.