On Mar 19, 2015, at 5:06 PM, Gedare Bloom <[email protected]> wrote: > On Thu, Mar 19, 2015 at 12:00 PM, Ric Claus <[email protected]> wrote: >> >> On Mar 19, 2015, at 4:30 PM, Sebastian Huber >> <[email protected]> wrote: >> >>> >>> ----- Joel Sherrill <[email protected]> schrieb: >>>> >>>> >>>> On March 19, 2015 9:52:56 AM CDT, Gedare Bloom <[email protected]> wrote: >>>>> On Thu, Mar 19, 2015 at 10:49 AM, Joel Sherrill >>>>> <[email protected]> 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. _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
