ino_t type definition

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> 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__ 

so change this to 

#if defined(__MS_types__) || defined(__rtems__)

How does that look to you?

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

Amazingly so. :)

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

> 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