Donn Terry <yyyyyy@xxxxxxxxxxxxx> wrote, on Tue 13 Mar 2001:
>
> I spent a lot of time trying to craft wording based upon the group's
> discussion of a
> solution, and it simply doesn't work; having getpid() have the possibility
> of failing
> is a severe pain to deal with, and each time I try to fix the problem I find
> new ones.
People who are contemplating allowing getpid() to fail should stop it NOW.
The concept of a process that can't find out its own PID is just utterly
ridiculous!
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.
> Excepting those 4 types (uid_t, gid_t, id_t and pid_t) seems to be the least
> painful
> (to the application writer) solution to the problem.
The "problem" is an artificial one of your own making, not a problem
with the [proposed changes to the] standard.
If you want to have a strange environment where uid_t is 64-bit and
long is 32-bit, for whatever reason (which you still haven't explained),
then you can. It just won't be a POSIX-conforming environment. In order
to comply with the standard you would have to provide another environment
where either:
a) long is 64-bit, or
b) uid_t is 32-bit. (This environment would only be enabled
for system configurations which disallow large UID values.)
> (Before this proposal came up,
> there was no problem, because vendors could extend uid_t everywhere.)
The only way to extend uid_t to be bigger than [unsigned] long int, and
remain compliant with POSIX.1-1996, is to make it be double or long double.
You don't think that would cause any problems?
--
Geoff Clare yyy@xxxxxxxxxxx
UniSoft Limited, London, England. yyy@xxxxxxxxxx
|