[PATCH] rtems: Fix sp2038 test.

[Sebastian Huber]

On 2014-04-28 00:30, Chris Johns 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.

Yes, it fixes the test, but it doesn't fix the problem.  Anyone using the POSIX 
date and time API uses the Newlib code.

>
>> 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.

I would rather fix this problem later.

>
>> 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.

I guess we will have a RTEMS 4.12 or so before 2038, so there is no immediate 
need to fix it now.

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.