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. > Ric > > _______________________________________________ > devel mailing list > [email protected] > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
