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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 13:01:29 2024 UTC