Re: Comments on XBDd5 ERN 322

[yyyyyyyyy@xxxxxxxxxxxx]

>From: Paul Eggert <yyyyyy@xxxxxxxxxxx>

>> 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.


I would better live with a 64 bit pid_t than with an application that
probably cannot retrieve it's own pid.


On the other side uid_t being 64 bit will definitely create headakes.
Just think about existsing portable filesystem standards  like
Rock Ridge (*) where uid_t is fixed to 32 bits.

I cannot speak for UDF at the moment as I have the standard at home :-(

Jörg

 EMail:yyyyy@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
       yy@xxxxxxxxxxxxxxx               (uni)  If you don't have iso-8859-1
       yyyyyyyyy@xxxxxxxxxxxx           (work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix