BUGFIX: TDB.C and TDBTOOL.C from Jul 9th CVS snapshot.
mbeattie at sable.ox.ac.uk
Thu Jul 12 15:37:41 GMT 2001
John E. Malmberg writes:
> 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"
> > >
> > > 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've just looked and Section 2.6 "Primitive System Data Types" includes
Table 2-1. Primitive System Data Types
Defined Type Description
ino_t Used for file serial numbers.
All of the types listed in Table 2-1 shall be arithmetic types
That pretty much leaves them without a leg to stand on.
Note that "arithmetic type" is an ANSI/ISO-C-ism defined in 220.127.116.11
(ANSI numbering) which means exactly what you'd expect it to mean so
they can't weasel out by claiming an array of three shorts is an
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