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

[Malcolm Beattie]

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:

 SYNOPSIS

     #include <sys/types.h>

 DESCRIPTION

     The <sys/types.h> header includes definitions for at least the
     following types:
[...]
    ino_t  Used for file serial numbers. 
[...]
     All of the types are defined as arithmetic types of an appropriate
     length, with the following exceptions: key_t, pthread_attr_t,
     pthread_cond_t, pthread_condattr_t, pthread_key_t,
     pthread_mutex_t, pthread_mutexattr_t, pthread_once_t,
     pthread_rwlock_t and pthread_rwlockattr_t. Additionally, blkcnt_t
     and off_t are  extended signed integral types, fsblkcnt_t,
     fsfilcnt_t and ino_t are defined as  extended unsigned integral
     types

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.

--Malcolm

-- 
Malcolm Beattie <mbeattie at sable.ox.ac.uk>   <-- This email address will break
Unix Systems Programmer                   when I quit OUCS on Jul 20th. Send
Oxford University Computing Services    private mail to mbeattie at clueful.co.uk
                                      I'll sort out my IBM email address soon.