[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
signature.asc
Description: PGP signature
- Re: [Acl-devel] typo in acl_get_perm?,
Corinna Vinschen <=