Ted, Paul, Joe, Geoff, et al,
I think we've been side tracked. The current draft of the
revision requires that uid_t and gid_t be arithmetic types, that pid_t
be a signed integer type, and that id_t be capable of holding a pid_t,
uid_t, and gid_t values. This is the same requirement that was present
in POSIX.1-1996.
Since the revision has aligned with the 1999 C Standard, the
revision allows a pid_t to be a long long int and allows id_t, gid_t,
and uid_t to be complex floating types. There is no requirement here
that a long be a 64-bit entity in order to have a 64-bit process ID in
an implementation conforming to the revised standard.
Geoff started a discussion of existing applications "needing" a
"restricted" environment to be supplied by implementations conforming
to the revised spec such that applications that conformed to the 1990
POSIX standard wouldn't have to be ported to work under the 200x
POSIX standard. This is a great goal, and Donn took the action item to
rewrite various parts of the draft to try to make this hold together as
much as possible. We discussed in the ballot resolution meeting in
Alameda whether id_t, gid_t, uid_t, and pid_t should be added to the
list guaranteed to fit in a long in these "restricted" environments
even though there was no requirement for this for id_t, gid_t, and
uid_t in the 1996 standard. We decided to try to make that guarantee
unless we found a reason why it couldn't be done. The discussions here
have made it clear that it can't be done without serious
repercussions. Therefore, these types should be removed from the list
of types guaranteed to fit in a long in the "restricted" environments
provided by the revision.
It can still be argued that pid_t is different from the others
since the 1996 standard and the current draft require that pid_t be a
signed integer type. In the 1996 standard, that meant that pid_t was
no bigger than long int. In the revision, it could be signed long long
int or an implementation specific signed longer int. Any application
that assumes that pid_t will fit in a long (rather than an arbitrary
width integer type) is not a conforming application according to the
revised draft standard.
Personally, for the next 5 years, I'm happy to guarantee that
the operating systems my company provides won't break any applications
that depend on getpid() returning an integer type that can be held in a
long. (Note well that this is a personal guarantee; not an official
statement of any kind by Sun Microsystems, Inc.) But, I'm not sure I'm
willing to extend that guarantee for over a decade. Note that we are
now performing the first revision of IEEE Std 1003.1-1990. When we
move to a 128-bit architecture, it makes perfect sense to me that the
type widths should be something like:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
long long 128 bits
and I don't want to write a standard now that precludes this when the
time comes. And, I don't want to declare now that I won't need to make
pid_t a 128-bit entity.
I fully expect that applications written to a 1990 (or even
1996) standard will be around for a while and should continue to
function correctly on any POSIX.1-1990 conforming implemnentation. Any
implementation that claims to conform to the 1990 standard must make
this true. However, I do not expect that code written in 1990 can be
recompiled with no changes and claim that it conforms to a new standard
that we are writing now. When I get the point that I have to support
128-bit pid_t's, I will have to stop claiming to support SVID3, XPG3,
UNIX '95, UNIX '98, POSIX.1-1990(and it various amendments) conforming
applications. It shoulnd't mean that I won't be able to conform to
POSIX.1-200x unless I artificially inflate a long to be 128 bits
instead of using the logical long long that obviously fits this
position so well.
I've seen all the discussion about how long it will be before
we have 128-bit hardware. I've also seen the discussions saying that
we have to support applications that were written over 10 years ago
without the possibility of them being ported to the current standard.
I'm saying the transition to the current spec needs to start now; not
in 2012, and certainly not never.
I hope that at this point Donn can go back and give us one more
pass on his proposed changes dropping the support for gid_t, id_t,
pid_t, and uid_t being restricted to no wider than long. This will
match what Geoff requested in his aardvark input and will give all of
us something we should be able to live with.
Thanks,
Don
>From yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx Tue Mar 13 10:24:39 2001
>Resent-Date: 13 Mar 2001 18:22:39 -0000
>From: Ted Baker <yyyyy@xxxxxxxxxxxxxx>
>To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx, yyyyyy@xxxxxxxxxxx
>Subject: Re: Comments on XBDd5 ERN 322
>Resent-Message-ID: <yyyyyyyyyyyyyyyyy@xxxxxxx>
>Resent-To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-From: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>X-Mailing-List: austin-group-l:archive/latest/2927
>X-Loop: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-Sender: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>
>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
>
>
|