----- Gedare Bloom <ged...@rtems.org> schrieb:
> 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.
This ino_t is used by all file systems and should have at least 32-bits.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
