What happens if xTimeToWake overflows in xTaskDelayUntil

Kernel
1

While debugging I found the call to prvAddCurrentTaskToDelayedList in xTaskDelayUntil() and wondered what would happen if xTimeToWake overflowed on that spot, but xConstTickCount didn’t.
In this case xConstTickCount would have a value somewhat close to MAX(TickType_t) and xTimeToWake would have a small value, leading to extremly long wait times passed to the call.

As overflowing is taken into account in the code right before that I’m wondering if I’m missing something here or if this could become a real issue.
Can someone explain this to me?

Edit: Wanted to link to the code but I’m too new of a user^^
It’s in line 1311 in task.c at revision fa0f5c4

2

The scheduler is suspended before prvAddCurrentTaskToDelayedList() is called, so the tick count can’t change at that point.

3

Yes, but xTimeToWake can.
But I also missed, that the overflow of xTimeToWake would cancel out with the underflow happening for (xTimeToWake - xConstTickCount) when xConstTickCount didn’t overflow.