On Thu, Mar 19, 2015 at 1:10 PM, Ric Claus <[email protected]> wrote: > > 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. 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 > [email protected] > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
