John Nemeth wrote:

> On Aug 31,  5:25pm, Klaus Klein wrote:
> } On Sun, Apr 10, 2005 at 12:21:30PM -0700, John Nemeth wrote:
> } 
> } > The POSIX definition of getpwnam_r is located here:
> } > 
> } > http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam.html
> } > 
> } > At the above URL, there are no error codes listed that can be used to
> } > indicate the entry wasn't found.  The Solaris manpage says that in this
> } > case, it returns 0 and sets the result to NULL.  The NetBSD manpage
> } > doesn't specifically mention this case.  The NetBSD code returns ENOENT
> } > in this case.
> } 
> } [...]
> } 
> } > Should NetBSD code follow the Solaris way for maximum
> } > portability?
> } 
> } The issue here is that the standard does distinguish between
> } "successfully no entry found" and "an error caused no entry to be
> } found", viz. "A NULL pointer shall be returned at the location pointed
> } to by result on error _or_ if the requested entry is not found"
> } (getpwnam_r, emphasis added by me).  Its wording is less concise
> 
>      I'm a native English speaker and I find the sublties here to be
> somewhat challenging.  It seems to me that what you are saying is that
> if they single out a condition, then it should be treated seperately
> from other cases.

Yes.  I recommend also having a look at Nathan's comment; the rest
of the document text backs this concept.

>      To me, "not found" is an error just like any other error and
> returning ENOENT as NetBSD does now is probably the right thing.
> However, that isn't the way the rest of the world works.

It is not the right thing.  As things stand now there is no way to
inform the caller of a non-error lookup failure.  This is a useful
distinction to have, e.g. whether nor not to cache such a result.

> } for getpwnam, but comparing -current against 2.0 shows a regression
> } in now setting errno to ENOENT in the former case.
> 
>      getpw*_r is new for 3.0 (recent -current).  It didn't exist in
> 2.0.

Right, I couldn't fail to notice.  I checked getpwnam(), just as the
excerpt from my mail indicates, because there is no functional
difference spec'ed in the success/lookup-failed/error behavior
between it and getpwnam_r() other than the use of function return
value and errno vs. call-by-reference argument and function return
value.

2.x and earlier distinguish between these conditions; -current does
not.  getpwnam_r() is new and does not; getpwnam() regressed.


I hope this serves to clarify matters somewhat...
- Klaus