acl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Acl-devel] typo in acl_get_perm?


From: Corinna Vinschen
Subject: Re: [Acl-devel] typo in acl_get_perm?
Date: Thu, 7 Jan 2016 10:32:48 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Dec 27 23:23, Andreas Grünbacher wrote:
> 2015-12-27 20:51 GMT+01:00 Corinna Vinschen <address@hidden>:
> > [...]
> > Ok, sorry if my mail was unclear on that point.  Let me try again:
> >
> > Perm is an acl_perm_t, which consists of any combination of ACL_READ|
> > ACL_WRITE|ACL_EXECUTE.
> 
> Type acl_perm_t is actually not defined as a bit field; it is not a
> requirement that the values of ACL_READ, ACL_WRITE, and ACL_EXECUTE
> can be bitwise combined. Other implementations of this interface might
> use bit numbers instead of bit masks, for example.

I re-read the IEEE draft and it only claims acl_perm_t holds an
individual permission.  I never understood that as only one of the
allowed values before, always as the usual permssion combination 'rwx'.
Oh well.  

> If acl_perm_t was defined as a bit field, there would be no point in
> having functions like acl_add_perm, acl_delete_perm, acl_get_perm, or
> a separate type acl_permset_t, and bit operations could be used
> instead.

I was already wondering about the "unnecessary" complexity of the API.

> [...]
> 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.

Ok.


Thanks,
Corinna

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]