php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #81649 imap_(un)delete accept sequences, not single numbers
Submitted: 2021-11-22 13:58 UTC Modified: 2021-11-24 16:05 UTC
From: valeri dot geiser at km-logistik-service dot de Assigned:
Status: Closed Package: IMAP related
PHP Version: 7.4.26 OS: Debian GNU/Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: valeri dot geiser at km-logistik-service dot de
New email:
PHP Version: OS:

 

 [2021-11-22 13:58 UTC] valeri dot geiser at km-logistik-service dot de 
Description:
------------
imap_delete and imap_undelete use string $message_num in the signature whereas all other functions use int $message_num:
imap_body
imap_bodystruct
imap_bodystruct
imap_fetchbody
imap_fetchheader
imap_fetchmime
imap_fetchstructure
imap_fetchtext
imap_header
imap_headerinfo
imap_savebody
imap_uid

This is incosistent (at least from user point of view) and leads to errors. 

Expected result:
----------------
Signature consistently using int as type for $message_num

Patches

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-11-22 14:36 UTC] cmb@php.net 
Contrary to the other functions, imap_delete() and imap_undelete()
actually accept a *sequence*, and from lib-cclient's internal.txt[1]:

| [Note!!  There is an important difference between a "sequence" and a
|  "msgno".  A sequence is a string representing one or more messages in
|  IMAP4-style sequence format ("n", "n:m", or combination of these
|  delimited by commas), whereas a msgno is an int representing a single
|  message.]

So we cannot change the types, but may consider to change the
parameter names (although that would be a BC break wrt. named
parameters).  But in any way, we should fix the docs.

[1] <https://github.com/winlibs/imap/blob/imap-2007f/docs/internal.txt#L1255-L1259>
 [2021-11-22 15:05 UTC] valeri dot geiser at km-logistik-service dot de 
Then it should be consistent with the other ones that take sequences, i.e. it should be string $message_nums
as in imap_mail_copy and all(?) other functions that use sequences.
 [2021-11-22 16:08 UTC] cmb@php.net 
> […] i.e. it should be string $message_nums as in imap_mail_copy […]

Sounds right (modulo the BC break).

Anyhow, the docs have been fixed:
<https://github.com/php/doc-en/commit/620dfaa2440aeb9324ff34fa7b162eb7d64ae6b9>.
 [2021-11-23 06:47 UTC] valeri dot geiser at km-logistik-service dot de 
Imho, the bc break is neglectable, since named parameters are a relatively new feature and I cannot imagine that it is used that much yet. Also, I cannot imagine that the imap_* - functions are used in that many projects that already change to only support php8 (which has named parameters). In reality, these projects can only start to use this once only 8+ is supported.
Bottomline: The advantage of cleaning up the inconsitency is much higher than the possibility of bc breaks. my 2 cents :)
 [2021-11-24 16:05 UTC] cmb@php.net
-Summary: imap_delete uses string $message_num, other functions in $message_num +Summary: imap_(un)delete accept sequences, not single numbers
 [2021-11-24 16:05 UTC] cmb@php.net 
The following pull request has been associated:

Patch Name: Fix #81694: imap_(un)delete accept sequences, not single numbers
On GitHub:  https://github.com/php/php-src/pull/7686
Patch:      https://github.com/php/php-src/pull/7686.patch
 [2021-11-25 17:33 UTC] git@php.net 
Automatic comment on behalf of cmb69
Revision: https://github.com/php/php-src/commit/179030d167937b8ae5957839c655e37482143469
Log: Fix #81649: imap_(un)delete accept sequences, not single numbers
 [2021-11-25 17:33 UTC] git@php.net
-Status: Open +Status: Closed
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Oct 29 12:00:01 2025 UTC