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