On 12/24/2016 02:43 PM, G. Schlisio wrote:
>
> Am 24.12.2016 um 08:40 schrieb John Fawcett:
>> On 12/24/2016 01:19 AM, Wietse Venema wrote:
>>> John Fawcett:
>> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
>> /*result/ to /pwd/. If no matching password record was found, these
>> functions return 0 and store NULL in /*result/. In case of error, an
>> error number is returned, and NULL is stored in /*result/. "
>>> A zero result value mans that no error occurred; we know for certain
>>> that the user exists or does not exist.
>>>
>>> That's almost consistent with, for example, the XOPEN standard: \
>>>
>>> The getpwnam_r() function shall return zero on success or if
>>> the requested entry was not found AND NO ERROR HAS OCCURRED.
>>> If an error has occurred, an error number shall be returned to
>>> indicate the error.
>>>
>>> What bugs me is the text that follows later in that same Linux
>>> manpage:
>>>
>>> ERRORS
>>>
>>>0 or ENOENT or ESRCH or EBADF or EPERM or ...
>>> The given name or uid was not found.
>>>
>>> This text makes no sense. It is in conflict with XOPEN, and with
>>> the other quote from the Linux manpage.
>>>
>>> Wietse
>>>
>> Yes, at first I read the text under ERRORS as though it was part of the
>> standard, but then I realized that it is just stating what some
>> implementations do in practice (which is what makes no sense).
>>
>> John
> very interesting ideed. i took it to the arch mailing list [0], maybe we
> dig up there what changed recently with the glibc behaviour.
> atm the mailing list is on chrismas hibernation but that might change at
> some point.
> thank you a lot for your help and information and have a nice christmas!
>
> georg
>
Georg
I don't think there is enough evidence at the moment to say with
certainty that any change in glibc has introduced the problem, since you
were using that for a while now without seeing issues.
I'd still be interested in knowing what output the test program gives on
the affected server.
best wishes to you too.
John
