ino_t type definition

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Am Son, 2001-11-11 um 19.22 schrieb Victor V. Vengerov:
> > Hi,
> >
> > Joel Sherrill wrote:
> >
> > >
> > >
> > > > => Cygwin uses unsigned long.
> > > >
> > > > But this code also means that you can't rely on any implicit assumptions
> > > > on ino_t's size if your code is supposed to be portable.
> > >
> > > That statement applies to all types defined by C Standard Libraries and POSIX.
> > > You can't depend on anything size-wise.
> >
> > IMHO, that statement applies to application code: application code should not
> > depend on such limits. Eugene means that file system implementation inside
> > RTEMS may require more than 16 bit i-node. File system is not an
> > application-level
> > code. I think, file system code (which is part of specific POSIX system
> > implementation)
> > may use some assumptions about ino_t width.
> Hmm, I wouldn't not call this to be a good design.
> 
> Your code would probably break if ino_t was changed some time in future.
> Not very likely to happen ever, but recall it's just what you are
> proposing now.
> 
> > Are you agree with us that ino_t should be made wider?
> I don't see any reason for not doing so
> 
> (Unless something else in RTEMS, newlib, gcc silently and implicitly
> depends on having a short ino_t, of cause.)

I think it is safe to make it wider for RTEMS.  With the following
disclaimer.

If you are implementing a filesystem that requires ino_t to be larger
than 16-bits for compatability purposes, then I would highly recommend
using an explicit unsigned32 or whatever.  Say you are implementing
an EXT2 or Mac filesystem, compatability is more important.  If you
need ino_t to be> 16 bit when using that filesystem, then assert
in the mount that if ino_t is smaller. 

I say all of that because I would like to some day have a 
tiny RTEMS for 8 bit CPUs.



> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985