Is not one of the ways to manage delta-time
timeouts to use uptime() instead of time()?
You don't care what time it is, you only want
to manage a timeout on the order of seconds,
so a monotonic time source like uptime() is
actually preferable.

It seems to me that 64-bit math is unnecessarily
punitive, especially for many embedded processors.

Also, DST doesn't affect the value of time()
et al. at all, or should not.

-- Jim

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Adrian Szyndela
Sent: Wednesday, April 11, 2012 1:41 AM
To: [email protected]
Subject: [PATCH] arpping in udhcpc

Hi,

I'm attaching a patch for way too long wait on poll() during arpping
after IP address acquiring over DHCP.

It happens on a platform which starts with Epoch time. Then, at some
point, a correct time source appears, and an actual time is set.

If an actual time is set during wait on poll(), computing of a timeout
overflows on unsigned type. The patch just changes types to stay with
long long computing.

Before applying the patch the side effect of setting an actual time is
close to hangup - with no IP address assigned. After applying the patch
the side effect of time change is that poll() might wait shorter than
desired 2 seconds in case of socket activity.

I found a comment /* We don't expect to see 1000+ seconds delay,
unsigned is enough */ in networking/arping.c (which probably is affected
by the problem as well). The above case introduces 1000000000+ seconds
delay :). 3600 seconds at daylight saving time change is a piece of
cake.

Regards,
Adrian

_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to