----- Joel Sherrill <joel.sherr...@oarcorp.com> schrieb:
>
>
> On 3/19/2015 10:30 AM, Sebastian Huber 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).
> Should I add a debug check in the imfs initialization that this assumption
> is honored and disable this warning for the target in question?
>
> Unfortunately, disabling this warning will require a pragma and
> kernel.h in jfffs2 has the same issue at lines 13 and 14.
>
> Thoughts?
I would rather use a static assertion. What is this for a warning? Maybe we
can do a (ino_t)(intptr_t) node.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
