On Tue, Oct 14, 2014 at 2:21 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > On 14/10/14 04:21, Gedare Bloom wrote: >> >> cpukit/libcsupport/src/__assert.c52:43: >> warning: cast from pointer to integer of different size >> [-Wpointer-to-int-cast] >> rtems_fatal( RTEMS_FATAL_SOURCE_ASSERT, (rtems_fatal_code) >> &assert_context ); >> >> This code casts the address of assert_control into an >> rtems_fatal_code, which is uint32_t. I assume it was done so one can >> find the context while debugging, but it is non-portable behavior for >> 64-bit addresses. >> >> We could fix this a few ways: >> 1) Make rtems_fatal_code a uintptr_t type so it gets the same width as a >> pointer >> 2) Make rtems_fatal accept a uintptr_t type so it can get a wider int >> than rtems_fatal_code >> 3) Don't allow this abuse of rtems_fatal. A workaround could be to >> pass the offset in the frame of the assert_control. Less clean for >> debugging though. > > > 4) use "unsigned long" for Internal_errors_t since this type has at least > 32-bits in contrast to uintptr_t. This is already used for > RBTree_Compare_result. See also static assertions in > cpukit/score/src/rbtreeinsert.c. The rtems_task_argument has similar > issues. Maybe we should add a base integer type suitable for pointer storage > which is at least 32-bits wide. > It makes sense to me that there should be a ulongptr_t
> -- > 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