On 24/09/14 07:55, Chris Johns wrote:
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.
It is easy to make this RTEMS specific, but the problem itself is not RTEMS
specific.
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
