This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] nsswitch: Add group merging support

On 04/12/2016 01:53 PM, Mike Frysinger wrote:
>> You can _detect_ this behaviour by using an iterator to find these conflicting
>> entries and then play with /etc/nsswitch.conf to find the service which has
>> them and eventually remove them.
> what i previously requested was:
> 	could you clarify "undefined" ?  people could interpret this as memory
> 	corruption / crashes, while others are are inconsistent results.  i think
> 	we just want the latter.
> 	...
> 	in general i'm fine with "undefined", i would just prefer scoping it a
> 	bit.  it's "undefined" in terms of the result set, but it's not in terms
> 	of your program eating itself.
> so i don't think your desires are at odds with my request.  i simply want it
> to say that the return values (or whatever) are undefined rather than having
> the documentation imply all your programs will die an abort/assert crash, or
> enter the "undefined behavior" space like we have with "C undefined behavior".

I'm sorry, I missed that in your original response.

You raised a good point.

Let me rewrite it like this:

+When processing @samp{merge} for @samp{group} membership, the group GID
+and name must be identical for both entries.  If only one or the other is
+a match, the results are unspecified.

We use the C/C++/POSIX meaning of "unspecified behaviour" here.

That is to say that glibc imposes no requirements on what the results
should be if a misconfiguration is detected. However, the program is correct
and should not crash.

If you're OK with that then I'll use that wording.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]