ino_t type definition

[Ralf Corsepius]

Am Fre, 2001-11-09 um 14.14 schrieb Joel Sherrill:
> 
> 
> "Eugeny S. Mints" wrote:
> > 
> > Hi, All!
> > 
> > I investigated newlib-1.8.2 and 1.9.0 code and it seems
> > ino_t type defined for rtems as short in both. It seems in
> > this situation we will have a problem if, for example, create
> > more than 65536 files in IMFS. Unfortunately, for my MSDOS
> > fs implementation this is more important because of my
> > ino-to-file assignment algorithm which often uses ino
> > numbers greater than 0xFFFF. It seems int type more
> > appropriate for ino_t.
> > 
> > Comments?
> 
> This seems unnecessarily limiting.  What does Cygwin and the other
> newlib targets use?
cf. newlibs's sys/types.h:

#if defined (_WIN32) || defined (__CYGWIN__)
#define __MS_types__
#endif

#ifdef __i386__
#if defined (GO32) || defined (__MSDOS__)
#define __MS_types__
#endif
#endif
..
#ifdef __MS_types__
typedef unsigned long   ino_t;
#else
#ifdef __sparc__
typedef unsigned long   ino_t;
#else
typedef unsigned short  ino_t;
#endif
#endif

Weird and fishy, I'd say :)

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

Ralf