[apparmor] [PATCH 1/6] libapparmor: Use directory file descriptor in _aa_dirat_for_each()

John Johansen john.johansen at canonical.com
Thu Apr 2 00:51:15 UTC 2015


On 04/01/2015 02:37 PM, Seth Arnold wrote:
> On Wed, Apr 01, 2015 at 12:49:30PM -0500, Tyler Hicks wrote:
>>> I like the gist of this patch but I think the parameter shouldn't be named
>>> dirfd; if we ever need the dirent.h header back again, this'll cause no
>>> end of confusion. It'd be safer to just pick a less obvious name, dir_fd
>>> for example.
>>
>> Thanks for the review!
>>
>> The "dirfd" naming convention is used in all of the *at(2) calls:
>>
>>  int faccessat(int dirfd, const char *pathname, int mode, int flags);
>>  int fchmodat(int dirfd, const char *pathname, mode_t mode, int flags);
>>  int fstatat(int dirfd, const char *pathname, struct stat *buf, int flags);
>>  int openat(int dirfd, const char *pathname, int flags);
> 
> Interesting. I mean, dirfd is the first name that comes to mind for a
> directory file descriptor, so it shouldn't be too surprising, but I am a
> touch surprised collisions with dirfd(3) weren't considered first. Oh well.

Its a fn vs a variable, you can actually get away with them having the same
name without a collision (well at least in C/C++ with a good compiler).

> 
>>
>> That said, I don't mind changing it. I think prefer "dfd" over "dir_fd".
>> Does that sound good?
> 
> dfd is fine by me; I'm mostly interested in avoiding bikeshed discussions
> but figured if I was going to complain about the original name I should in
> all fairness have a suggestion. :)
> 
dirfd, dfd are both fine





More information about the AppArmor mailing list