__assert.c Wpointer-to-int-cast

[Gedare Bloom]

On Tue, Oct 14, 2014 at 2:21 AM, Sebastian Huber
<sebastian.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.