On Fri, Mar 4, 2016 at 12:25 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> > > On 03/03/16 23:44, Joel Sherrill wrote: > >> >> > >> > "be placed on Red-Black Trees for set management." copy-pasted >> comment >> > should be Chains? >> >> Thanks, for spotting this. >> >> > >> > "watchdog is scheduled and a black node". ditto, black should be red >> > for the second one. >> >> Oh, yes. >> >> > >> > _Watchdog_Ticks_from_seconds(): why is ticks = seconds<<30 the right >> > thing to do? Same for _Watchdog_Ticks_from_timespec(). I am missing >> > some assumption here, I guess. It might improve readability to >> provide >> > a helper function for this. >> >> Ok, sorry for the magic numbers. 2**30 == 1073741824 enough to >> cope with 1e9 nanoseconds. So, we have 2**34 seconds available, >> leading to a year 2514 problem. >> >> >> That's pretty close to the 2^64 nanosecond limit as I recall. So >> reasonable but >> I suppose that should be very explicit somewhere in a comment. >> >> Funny, before there was a wiki, we had a FAQ document which had a section >> on >> date/time overflow issues. We probably need a section in the users manual >> with >> the current truth on this: >> >> >> https://docs.rtems.org/releases/rtemsdocs-4.6.4/share/rtems/html/FAQ/FAQ00100.html >> >> We have multiple date/time and interval representations in the score, >> classic and >> POSIX APIs. It would be good to capture them again. >> > > Yes, this is on my TODO list along with the year 2038 problem. > > I thought we had discussed on newlib just changing time_t to 64 bits for RTEMS. But clearly the code still has it as a long. That seems to be the most straightforward solution. --joel > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
