> Date: Tue, 13 Mar 2001 12:38:18 -0800 (PST)
> From: Don Cragun <yyy@xxxxxxxxxxxxxxxxxxx>
> 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.
But we're not talking about code written in 1990. We're talking about
code being written as we speak, and code written between now and when
the new standard is issued and conforming implementations become
available (which won't happen for many months). Such code has to be
written to the current standard, which was published in 1996.
> When I get the point that I have to support 128-bit pid_t's,
That will be decades from now, if ever. We don't need to worry about
it in this iteration of the standard. And even if a miracle occurs
and you do need to worry about it before 2010, you can easily solve
the problem by using C99 types like int64_t and int128_t. With C99,
you no longer need to artificially truncate 'long' to be a smaller
type than is natural for your hypothetical 128-bit architecture.
> 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
My main concern is not with "dusty decks" written a decade or more
ago. I'm mostly worried about software that that is being written and
maintained today, tomorrow, and for the next few years.
Living programs have to be portable to a wide variety of popular
systems. Once 1003.1-200x comes out, there will be several years in
which portable programs will need to run on both 1003.1-1996 hosts and
1003.1-200x hosts. Unless systems provide an environment where types
like size_t and pid_t fit into long, there will be a several-year
period during which app writers can't easily maintain portable
programs.
> 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.
pid_t should not be in that list; it's always been an integer type.
And I would argue that gid_t and uid_t should not be in that list
either. Sure, the 1996 standard says that they can be floating point;
but nobody has ever implemented it that way, so in practice programs
that assume they fit into long have been portable. Andries Brouwer's
recently circulated outpid function is just one example of this.
d5 contains examples that assume that uid_t and gid_t fit into long.
I don't see why app writers should be punished for making the same
assumption.
|