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

Malcolm Beattie mbeattie at sable.ox.ac.uk
Wed Jul 11 13:36:33 GMT 2001

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:


     #include <sys/types.h>


     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


So if they're trying to keep up with SUSv2, you could try to beat
them into compliance after all.


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.

More information about the samba-technical mailing list