Date: Sun, 11 Dec 2022 04:47:57 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 265395] mail/squirrelmail: INBOX does not populate messages after upgrading php 7.4 to php 8.0 Message-ID: <bug-265395-7788-5JM2nJ7HA7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265395-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-265395-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265395 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 =3D ($hh * 60 + $mm) * 60; ++ $iTzc =3D ((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 =3D -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.int= eger.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 th= em 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, h= ands it over till it breaks now with php8 in the numeric calculation area.=20 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.=20 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 mail= s. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265395-7788-5JM2nJ7HA7>