"days", as calculated, can't be negative. Drop the respective loop and
change its type. Similarly "rem" can't be negative and doesn't require
more than 32 bits. Change its type, too.

As a consequence, the tm_wday calculation also can't yield negative
values, so the respective conditional can be dropped as well.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- unstable.orig/xen/common/time.c	2025-07-22 16:21:18.000000000 +0200
+++ unstable/xen/common/time.c	2026-05-07 12:22:11.687769995 +0200
@@ -45,7 +45,8 @@ static DEFINE_SPINLOCK(wc_lock);
 struct tm gmtime(unsigned long t)
 {
     struct tm tbuf;
-    long days, rem;
+    unsigned long days;
+    unsigned int rem;
     int y;
     const unsigned short int *ip;
 
@@ -70,18 +71,11 @@ struct tm gmtime(unsigned long t)
     tbuf.tm_sec = rem % 60;
     /* January 1, 1970 was a Thursday.  */
     tbuf.tm_wday = (4 + days) % 7;
-    if ( tbuf.tm_wday < 0 )
-        tbuf.tm_wday += 7;
     while ( days >= (rem = __isleap(y) ? 366 : 365) )
     {
         ++y;
         days -= rem;
     }
-    while ( days < 0 )
-    {
-        --y;
-        days += __isleap(y) ? 366 : 365;
-    }
     tbuf.tm_year = y - 1900;
     tbuf.tm_yday = days;
     /* SAF-14-safe use boolean as an array index */

On 08/05/2026 2:31 pm, Jan Beulich wrote:
> "days", as calculated, can't be negative. Drop the respective loop and
> change its type. Similarly "rem" can't be negative and doesn't require
> more than 32 bits. Change its type, too.
>
> As a consequence, the tm_wday calculation also can't yield negative
> values, so the respective conditional can be dropped as well.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

But, I really would prefer to rip this out entirely.

This is used by exactly 2 things.  One is a console timestamp mode that
isn't synchronised with dom0 updates to the RTC so of dubious utility in
reality, and the other is for an intermediate representation of some of
the emulation logic ported from QEMU, which I think we can remove
entirely by swapping to s_time_t instead.

This will fix a whole raft of MISRA violations about use of unsafe
library functions.  We're safe because we are not C-compatible (return
by value not by pointer), but a better option would be to remove it
entirely.

~Andrew