Subject: Re: getpw*_r standards
To: Klaus Klein <kleink@mibh.de>
From: John Nemeth <jnemeth@victoria.tc.ca>
List: current-users
Date: 04/11/2005 04:11:06
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.
}
} > Is it standards compliant to return codes not mentioned
} > in the standard?
}
} Per se it is, as long it does not conflict with the standard.
} However there's further details involved 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.
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.
} 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.
} So yes, we should change the implementation, including the result
} pointer location being set to NULL in the error (non-zero return)
} case.
Hmm... Time to sweep the tree again. This time for improper use
of getpw*_r.
} Thanks for catching this!
Your welcome. Although, it did partly come out of a private
conversation with Christos and my getpw* sweep of the tree.
}-- End of excerpt from Klaus Klein