Re: [Acl-devel] typo in acl_get_perm?

[Mike Frysinger]

On 27 Dec 2015 23:23, Andreas Grünbacher wrote:
> 2015-12-27 20:51 GMT+01:00 Corinna Vinschen <address@hidden>:
> > It's not clear from the man page that only a
> > single permission bit is allowed here, rather than an arbitrary
> > combination of the above bits.
> 
> The acl_add_perm, acl_delete_perm, and acl_get_perm man pages all
> refer to a permission (singular) for the acl_perm_t argument. This
> seems to correctly describe the interface, it is not overly verbose
> though. Maybe we can make it harder to misread things.

i think confusion arises from the word "permission".  colloquially, i
think it's accepted to say things like "what is the file permission",
or "do you have permission [to read or execute]?".

maybe 

> > Alternatively, if a bit combination is allowed as in acl_add_perm and
> > acl_delete_perm, the test in the code is ok, but the evaluation of the
> > return value is not (a&b!=0 vs. ~a&b==0).
> 
> It is undefined what acl_get_perm does when its perm argument is not
> one of ACL_READ, ACL_WRITE, or ACL_EXECUTE. You are proposing a change
> of this undefined behavior. However, this change could break code that
> (wrongly) relies on the current behavior.

hmm, am i missing something, or are those values not defined in any man
page ?  nor is acl_perm_t defined ?  acl_equiv_mode is the only page i
can see that mentions ACL_{READ,WRITE,EXECUTE}, and the add/delete/get
pages are the only ones that list acl_perm_t.  i guess the expectation
is you have another reference actively available including the headers
before you start coding.  otherwise i'd expect more details in acl(5).
-mike

signature.asc
Description: Digital signature