[PATCH] rtems: Fix sp2038 test.

[Gedare Bloom]

On Sun, Apr 27, 2014 at 6:30 PM, Chris Johns <chrisj at rtems.org> wrote:
> On 27/04/2014 10:23 pm, Sebastian Huber wrote:
>>
>> On 04/27/2014 10:17 AM, Chris Johns wrote:
>>>
>>> Avoid using newlib's gmtime_r call which fails with a max signed int.
>>> Add an RTEMS specific version for 1/1/1988 to 31/12/2100.
>>>
>>> Update sp2038 to test every day from 1/1/1988 to 31/12/2100. Only days
>>> need be tested as the code splits the seconds based on days.
>>
>>
>> This doesn't solve the problem with the year 2038 problem for the UNIX
>> 32-bit time.
>
>
> The test is about an RTEMS API that fails and the patch fixes the test.
>
+1, if there is still a 2038 problem then the test should be expanded
to expose it.

>
>> I don't think we should duplicate the time code and
>> instead use the one from Newlib.
>
>
> I would rather have RTEMS contain and control this code at this point in
> time.
>
> If you wish to switch to a 64bit time_t and validate it and then do a
> performance test for this API against newlib please do however until then we
> should run with this change and fix the test and the RTEMS API.
>
>
>> We should change time_t to 64-bit instead.
>
>
> I do not think we should change this at this late stage of the release
> cycle. If we keep delaying we may just need a 2038 fix for 4.11 and I will
> need a 46 point font to see.
>
> Chris
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel