[rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC

Chris Johns chrisj at rtems.org
Wed Sep 24 05:55:38 UTC 2014


On 24/09/2014 3:51 pm, Sebastian Huber wrote:
> On 24/09/14 07:45, Chris Johns wrote:
>> On 24/09/2014 3:42 pm, Sebastian Huber wrote:
>>> On 24/09/14 07:34, Chris Johns wrote:
>>>> On 24/09/2014 3:27 pm, Sebastian Huber wrote:
>>>>>
>>>>> Yes, we should move to 64-bit time_t after the next release or even
>>>>> now.
>>>>>
>>>>
>>>> What is involved ?
>>>
>>> Something like this:
>>>
>>> diff --git a/newlib/libc/include/machine/types.h
>>> b/newlib/libc/include/machine/types.h
>>> index 40a75fa..b7265b9 100644
>>> --- a/newlib/libc/include/machine/types.h
>>> +++ b/newlib/libc/include/machine/types.h
>>> @@ -11,7 +11,7 @@
>>>   #endif
>>>
>>>   #define _CLOCK_T_       unsigned long           /* clock() */
>>> -#define _TIME_T_        long                    /* time() */
>>> +#define _TIME_T_        long long               /* time() */
>>>   #define _CLOCKID_T_    unsigned long
>>>   #define _TIMER_T_      unsigned long
>>
>> This is common to all newlib users. Did you mean to do that ?
>
> Yes, we all use roughly the same time.  Maybe we should propose this
> right after the next Newlib release.
>

I suspect this would be rejected in favour of keeping 32bit support and 
providing optional 64bit support. Small memory targets would have 
storage issues.

Chris


More information about the devel mailing list