[Bug 265395] mail/squirrelmail: INBOX does not populate messages after upgrading php 7.4 to php 8.0

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265395

LadeSchale <flo@ostamt.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |flo@ostamt.de

--- Comment #4 from LadeSchale <flo@ostamt.de> ---
 Hello,

found this bugreport after we got it fixed, great :)

In reference to a similar problem/solution here
https://stackoverflow.com/questions/66238017/fatal-error-uncaught-typeerror-unsupported-operand-types-string-int-in/66238404#66238404

we fixed it direct were calculation happens, in line 91


-- $iTzc = ($hh * 60 + $mm) * 60;
++ $iTzc = ((int)$hh * 60 + (int)$mm) * 60;


in the following line 92 variable $iTzc was already used as an integer in a
calculation

if ($neg) $iTzc = -1 * (int) $iTzc;


For the question, should use with any PHP version? Reference says yes since
PHP4
https://www.php.net/manual/en/function.intval.php
https://www.php.net/manual/en/language.types.integer.php#language.types.integer.casting


But anyhow, further diving ...there is a bug report open since Aug 2020 with
same case
https://sourceforge.net/p/squirrelmail/bugs/2855/

Turns out this function picks up timezones from mailheaders and corrects them
for localtime. They will be collect as strings, i think cause of "+" and "-" in
front of timezone, like +0100. When everything is well formatted no strings
reach the calculation line, under normal circumstances.
Affected mails are not correct formated, in my case in the date field (set by
senders mua).

Correct mails look like this:
"Date: Thu, 25 Feb 2016 12:51:36 +0000"
or
"for <mail@example.com>; Fri, 30 Sep 2016 18:41:57 +0100 (BST)"

an affected mail, example from my case is missing timezonecode
"Date: Fri, 30 Sep 2016 17:41:57 UT   "

squirrelmail picks up the "UT   " as string, cause expect timezone there, hands
it over till it breaks now with php8 in the numeric calculation area. 
Pretty sure also that in this case non timezone correction could had done in
the past, also with less restrictive php versions. I guess an uncorrected or
wrong timestamp would had displayed to the user.

Means a real bugfix go in direction of approving, is the picked up string
useful for what we wanna do with it. 


What we have now is more a workaround to reach a higher good the non
complaining end user who could not list mailboxes with wrong formatted mails.

-- 
You are receiving this mail because:
You are the assignee for the bug.