ino_t type definition

[Ralf Corsepius]

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.)

Ralf