BUGFIX: TDB.C and TDBTOOL.C from Jul 9th CVS snapshot.
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"
> 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:
The <sys/types.h> header includes definitions for at least the
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