On Thu, Mar 19, 2015 at 11:30 AM, 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).
Then it should be safe to use uintptr_t instead: sizeof(IMFS_jnode_t
*) == sizeof(uintptr_t). For the 16/24-bit address spaces, this means
there should be less than 1<<16 or 1<<24 nodes, it seems reasonable.
For 32-bit archs we have no difference.
Gedare
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
