> From: yyy@xxxxxxxxxxx (Geoff Clare)
> Date: Tue, 13 Mar 2001 16:09:45 +0000
> Whatever choices these people made that led them to start thinking about
> letting getpid() fail were incorrect choices. They need to backtrack
> and make different choices based on an absolute requirement that getpid()
> must never fail.
I have to agree. If the standard were changed to say that getpid(),
getuid(), etc. could fail, that would invalidate lots of practical,
working code, and the vast majority of POSIX application writers would
simply shrug and ignore the standard.
Application writers have better things to do with their time than
cater to unnecessary complexity like that. Let's use a better
approach. Making getpid() and getuid() fail is a non-starter.
> From: Donn Terry <yyyyyy@xxxxxxxxxxxxx>
> Date: Tue, 13 Mar 2001 07:12:01 -0800
>
> Even on systems that have NO interest in going to 32 bit pointers, uid_t and
> friends are going to have to be "big", and very soon.
That's easily done too: one can use 64-bit 'long' along with 32-bit pointers.
> (In fact, I believe that other folks than I will have to deal with
> it sooner than I.)
Standardization is about tradeoffs. I would like to hear details
about their (and your) applications before saying that combining
64-bit uid_t with 32-bit long is so important that it's OK for the
standard to break lots of widely used and popular applications in
order to get it.
Right now, no shipping systems have wider-than-long uid_t. Since we
have no implementation experience with these systems, it seems unwise
for the committee to make inventions in this area. We should gain
implementation experience with these systems first.
|