<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 30, 2022 at 9:53 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 30/08/2022 16:37, Joel Sherrill wrote:<br>
> <br>
> On Tue, Aug 30, 2022 at 8:44 AM Sebastian Huber <br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
> <br>
>     On 30/08/2022 15:40, Joel Sherrill wrote:<br>
>      ><br>
>      ><br>
>      > On Tue, Aug 30, 2022 at 12:05 AM Sebastian Huber<br>
>      > <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>><br>
>      > <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>>> wrote:<br>
>      ><br>
>      >     On 30/08/2022 00:56, <a href="mailto:scan-admin@coverity.com" target="_blank">scan-admin@coverity.com</a><br>
>     <mailto:<a href="mailto:scan-admin@coverity.com" target="_blank">scan-admin@coverity.com</a>><br>
>      >     <mailto:<a href="mailto:scan-admin@coverity.com" target="_blank">scan-admin@coverity.com</a><br>
>     <mailto:<a href="mailto:scan-admin@coverity.com" target="_blank">scan-admin@coverity.com</a>>> wrote:<br>
>      >      > ** CID 1512552:  High impact quality  (Y2K38_SAFETY)<br>
>      >      > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()<br>
>      >      ><br>
>      >      ><br>
>      >      ><br>
>      >   <br>
>       ________________________________________________________________________________________________________<br>
>      >      > *** CID 1512552:  High impact quality  (Y2K38_SAFETY)<br>
>      >      > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()<br>
>      >      > 1798          /* Go live with the new struct timehands. */<br>
>      >      > 1799     #ifdef FFCLOCK<br>
>      >      > 1800          switch (sysclock_active) {<br>
>      >      > 1801          case SYSCLOCK_FBCK:<br>
>      >      > 1802     #endif<br>
>      >      > 1803                  time_second = th->th_microtime.tv_sec;<br>
>      >      >>>>      CID 1512552:  High impact quality  (Y2K38_SAFETY)<br>
>      >      >>>>      A "time_t" value is stored in an integer with too few<br>
>      >     bits to accommodate it.  The expression "th->th_offset.sec"<br>
>     is cast<br>
>      >     to "int32_t".<br>
>      >      > 1804                  time_uptime = th->th_offset.sec;<br>
>      >      > 1805     #ifdef FFCLOCK<br>
>      >      > 1806                  break;<br>
>      >      > 1807          case SYSCLOCK_FFWD:<br>
>      >      > 1808                  time_second =<br>
>     fftimehands->tick_time_lerp.sec;<br>
>      >      > 1809                  time_uptime =<br>
>      >     fftimehands->tick_time_lerp.sec - ffclock_boottime.sec;<br>
>      >      ><br>
>      >      > ** CID 1512551:    (Y2K38_SAFETY)<br>
>      ><br>
>      >     This seems to be a new Coverity feature. The Newlib time_t<br>
>      >     definition is:<br>
>      ><br>
>      >     #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffffffL<br>
>      >     #define _TIME_T_ long<br>
>      >     #else<br>
>      >     #define _TIME_T_ __int_least64_t<br>
>      >     #endif<br>
>      >     typedef _TIME_T_        __time_t;<br>
>      ><br>
>      >     Does Coverity use the Newlib header files? The<br>
>     _USE_LONG_TIME_T should<br>
>      >     be undefined for RTEMS.<br>
>      ><br>
>      ><br>
>      > Yes it should. It works by doing something like this:<br>
>      ><br>
>      > cov-build waf|make<br>
>      ><br>
>      > And looking at the newlib headers, I agree everything looks like<br>
>     it should<br>
>      > be defined to _int_least64_t. And preprocessing a simple file<br>
>     that includes<br>
>      > <sys/time.h> shows that it is typed to that.<br>
>      ><br>
>      > But.... something else is going on. time_uptime is defined to<br>
>      > _Timecounter_Time_uptime<br>
>      > which is an int32_t.<br>
> <br>
>     Oh, sorry, I didn't notice this. Then this is a false positive.<br>
>     Using an<br>
>     int32_t for uptime seconds is enough.<br>
> <br>
> <br>
> The variable  time_uptime is still defined as two separate types. The<br>
> prototype and the declaration do not match.<br>
<br>
I think this is all right:<br>
<br>
#ifndef __rtems__<br>
volatile time_t time_second = 1;<br>
volatile time_t time_uptime = 1;<br>
#else /* __rtems__ */<br>
volatile time_t time_second = TOD_SECONDS_1970_THROUGH_1988;<br>
volatile int32_t time_uptime = 1;<br>
#endif /* __rtems__ */<br>
<br>
> <br>
> Even if int32_t is wide enough for seconds of uptime, it is an assignment<br>
> that narrows types. Casting to make this narrowing intentional would at<br>
> least hint this was intentional.<br>
<br>
 From looking at the other Y2K38_SAFETY reports, a cast probably doesn't <br>
help to get rid of it.<br>
<br>
> <br>
> But better would be to use the proper type and just make it time_t like<br>
> FreeBSD.<br>
<br>
The time_uptime is used in the libbsd. This is a performance optimization.<br></blockquote><div><br></div><div>And the declaration you show is mismatched because of these:</div><div><br></div>cpukit/include/machine/_kernel_time.h:#define   time_uptime _Timecounter_Time_uptime<br><div>cpukit/include/rtems/score/timecounter.h:extern volatile int32_t _Timecounter_Time_uptime;</div><div><br></div><div>This is inconsistent with the declaration of time_uptime above.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There is also an unsolved issue with the time_second. On 32-bit targets <br>
you can't reliably read this value.<br></blockquote><div><br></div><div>I assume you mean because it will take two accesses? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
</blockquote></div></div>