On Thu, Mar 19, 2015 at 1:10 PM, Ric Claus <cl...@slac.stanford.edu> wrote:
>
> On Mar 19, 2015, at 5:06 PM, Gedare Bloom <ged...@gwu.edu> wrote:
>
>> On Thu, Mar 19, 2015 at 12:00 PM, Ric Claus <cl...@slac.stanford.edu> wrote:
>>>
>>> On Mar 19, 2015, at 4:30 PM, Sebastian Huber
>>> <sebastian.hu...@embedded-brains.de> wrote:
>>>
>>>>
>>>> ----- Joel Sherrill <joel.sherr...@oarcorp.com> schrieb:
>>>>>
>>>>>
>>>>> On March 19, 2015 9:52:56 AM CDT, Gedare Bloom <ged...@rtems.org> wrote:
>>>>>> On Thu, Mar 19, 2015 at 10:49 AM, Joel Sherrill
>>>>>> <joel.sherr...@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.
I see. We'd have to see what the rules are for the implicit type then.
A quick test on my native (x86_64) host says it is a long int.
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
