Hi,
Philip Guenther wrote on Tue, Feb 18, 2014 at 08:55:00AM -0800:
> On Tue, 18 Feb 2014, Mark Kettenis wrote:
>> Ingo Schwarze <[email protected]> wrote:
>>> Philip Guenther wrote:
>>>> So: we need to
>>>> - clear errno in the success and "no match" cases,
>>> This is incorrect and shouldn't be done.
>>> When no error occurs, errno has to stay as it is.
>> Indeed. POSIX explicitly says:
>>
>> "No function in this volume of POSIX.1-2008 shall set errno to zero."
>>
>> The standard is slightly ambiguous on what getpwnam_r() should do, but
>> the way I read it, it should not touch errno at all. So it should
>> save errno at the start of the function, and restore it just before
>> return.
Yes, i guess that behaviour would conform to POSIX. However, the way
i read it, it is unspecified whether getpwnam_r() sets errno in
addition to returning the error code.
So we have two options:
a) leave the errno setting inside getpwnam_r(), as it is now
- advantage: less code changes
- advantage: getpnam_r() also sets errno, as in the past
b) move the errno setting to getpwnam() as proposed by kettenis@,
which would then look like (pseudocode):
getpwnam(...) {
ret = getpwnam_r(...);
if (ret) {
pw = NULL;
errno = ret;
} /* else, pw may or may not be NULL */
return (pw);
}
- disadvantage: more code changes in getpwnam_r()
- disadvantage: behaviour of getpwnam_r() changes
- advantage: code becomes simpler
- advantage: *maybe* a bit closer to POSIX spirit
I'd slightly favour option b), but could live with a), too.
> I guess I'll add "review the ports that use getpwnam() and getpwnam_r()
> for correctness" to my todo list as a dependency for this patch then.
Ouch, that triggered my sarcasm detector.
It's not as bad as that, i think. Right now, we don't clear errno,
and most stuff apparently works. There seem to be issues now and
then, but they can be dealt with as they arise.
What we are planning to do is just avoid setting errno when we shouldn't.
That won't make the problems worse than they are now, in ports land.
> Who's filing the bugs with Solaris and glibc, so that we don't have to
> push this boulder upstream against them?
I never filed bugs with glibc or Solaris, but could certainly do
that after we have fixed this in our own stuff. Then again,
it would probably add credibility if a member of the Austin working
group popped up over there, saying "hey! you are violating POSIX!",
compared to me saying so... ;-)
Yours,
Ingo
