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

[Ric Claus]

On Mar 19, 2015, at 5:06 PM, Gedare Bloom <gedare at gwu.edu> wrote:

> On Thu, Mar 19, 2015 at 12:00 PM, Ric Claus <claus at slac.stanford.edu> wrote:
>> 
>> On Mar 19, 2015, at 4:30 PM, Sebastian Huber <sebastian.huber at embedded-brains.de> 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).
>> 
> Using the intermediate cast to uintptr_t is fine. We should keep ino_t
> defined as a long.
> 
>> I’m curious what you all think about doing:
>> 
>>  return (const char*)node - (const char*)0;
>> 
> This still results in a pointer-type, the return value will be cast to
> ino_t implicitly and give a similar warning.

No, I don’t think so.  The difference of two pointers is the number of elements (chars in this case) between them.