BUGFIX: TDB.C and TDBTOOL.C from Jul 9th CVS snapshot.

[John E. Malmberg]

On Wed, 11 Jul 2001, Malcolm Beattie wrote:

> John E. Malmberg writes:
> > What am I really trying to fix?  I have an ino_t that is larger than the
> > maximum supported scaler integer type that can be handled on one of my
> > build platforms.
> [...]
> > The problem is that the ino_t type on OpenVMS is
> > 
> > "unsigned short st_ino[3]"
> > 
> > This basically breaks building any UNIX program that uses the ino_t
> > datatype on OpenVMS.
> [...]
> > And apparently nothing in The Open Group's official "Single Unix Standard"
> > actually states the the ino_t must be a scaler, so it can not be flaged as
> > a compliance bug.
> 
> SUSv2 (Single UNIX Specification Version 2) specifies as follows:
> 
Thankyou, this reference may help for in the future.

Do you happen to know if POSIX says anything also?

I still need to be able to deal with the VAX platform where it is not
possible to represent the ino_t in the largest integer type that the
compiler supports.

-John
wb8tyw at qsl.network.
 
> See
>     http://www.opengroup.org/onlinepubs/7908799/xsh/systypes.h.html
> 
> So if they're trying to keep up with SUSv2, you could try to beat
> them into compliance after all.

I am not sure exactly what their goals are in that regard.  Some of it
depends on how many more important things are in the queue.

Code that messes around with inodes can not be that common.

-John
wb8tyw at qsl.network