Subject: Re: getpw*_r standards
To: John Nemeth <firstname.lastname@example.org>
From: Klaus Klein <email@example.com>
Date: 04/19/2005 01:14:41
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
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
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...