imfs.h: warning cast from pointer to integer of different size

Joel Sherrill joel.sherrill at oarcorp.com
Thu Mar 19 15:34:39 UTC 2015



On 3/19/2015 10:30 AM, Sebastian Huber wrote:
> ----- Joel Sherrill <joel.sherrill at oarcorp.com> schrieb:
>>
>> On March 19, 2015 9:52:56 AM CDT, Gedare Bloom <gedare at rtems.org> wrote:
>>> On Thu, Mar 19, 2015 at 10:49 AM, Joel Sherrill
>>> <joel.sherrill at oarcorp.com> wrote:
>>>> Hi
>>>>
>>>> On one platform, we get a warning for this piece of code in imfs.h
>>>>
>>>> static inline ino_t IMFS_node_to_ino( const IMFS_jnode_t *node )
>>>> {
>>>>   return (ino_t) node;
>>>> }
>>>>
>>>> On this target, "typedef unsigned long ino_t;" and
>>>> sizeof(void *) < sizeof(unsigned long) so the cast is safe.
>>>>
>>>> Would we be better off with ino_t being uintptr_t since we
>>>> do cast it back and forth?
>>>>
>>>> Any other suggestions?
>>>>
>>> The safest fix is to use the new CPU_Uint32ptr type. This resolves to
>>> uintptr_t on most 32-bit+ archs.
>> The type ino_t is defined in newlib so this doesn't work.
> The only requirement on the ino number is that it uniquely indentifies a node in a file system.  We only have a problem if sizeof(IMFS_jnode_t *) > sizeof(long).
Should I add a debug check in the imfs initialization that this assumption
is honored and disable this warning for the target in question?

Unfortunately, disabling this warning will require a pragma and
kernel.h in jfffs2 has the same issue at lines 13 and 14.

Thoughts?

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985




More information about the devel mailing list