This (uid_t and pid_t) is the second round of discussions under
the Austin Group where I've seen an effort to accomodate systems
that use 64-bit values (sizes, user id's, process id's, etc.) in
the OS API but do not have 64-bit long integers.
I'm convinced that it is contrary to the interest of existing
POSIX/Unix users (including the US Government), application
developers, and the existing vendors or Unix-compliant operating
systems to adopt a standard that allows one to call such a system
"POSIX compliant".
It is only logical that if applications (through the OS API) need
to work with 64-bit values, the long integer type will be at least
64 bits.
Yes, I read the claims that somebody "needs" to support 64-bit
values in the API on a system with a 32-bit long integer type.
I'll accept that some vendor(s) may have decided they want to
support such an "oddball" environment, for some special need.
That does not justify breaking the usefulness of POSIX/Unix as a
portability standard for its existing market. The vendors who
want to support the oddball environment can do so, without calling
that environment "POSIX compliant".
In the e-mails I have not seen any solid justification for this
being a true need. The need for 64-bit values in these (process
ID, etc.) API types itself is new, so it is appropriate that
systems that support the new 64-bit values also support a new
64-bit long integer type. One cannot argue that one needs binary
compatibility with legacy 32-bit binaries (or an old ABI), since
presumably those binaries were compiled to expect 32-bit values
for the types in question, and so would break if passed 64-bit
values (an new applications compiled to the old ABI would also
break).
--Ted
|