[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ino_t type definition
- Date: 12 Nov 2001 05:35:26 +0100
- From: corsepiu at faw.uni-ulm.de (Ralf Corsepius)
- Subject: ino_t type definition
Am Son, 2001-11-11 um 19.22 schrieb Victor V. Vengerov:
> 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
> code. I think, file system code (which is part of specific POSIX system
> 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
> 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.)