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

[Malcolm Beattie]

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[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'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 6.1.2.5
(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
arithmetic type.

--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.