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 -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
