From: Michal Nazarewicz <mina86@mina86.com>
To: Oliver Neukum <oneukum@suse.com>,
Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: gregkh@linuxfoundation.org, k.kozlowski@samsung.com,
kyungmin.park@samsung.com, m.chehab@samsung.com,
m.szyprowski@samsung.com, peter.chen@freescale.com,
deepa.kernel@gmail.com, baolex.ni@intel.com,
chuansheng.liu@intel.com, mathias.nyman@linux.intel.com,
stern@rowland.harvard.edu, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 0984/1285] Replace numeric parameter like 0444 with macro
Date: Wed, 03 Aug 2016 13:15:34 +0200 [thread overview]
Message-ID: <xa1tpopqdrxl.fsf@mina86.com> (raw)
In-Reply-To: <1470213052.4612.1.camel@suse.com>
On Wed, Aug 03 2016, Oliver Neukum wrote:
> Before we think about that, the basic question whether
>
> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH
>
> is clearer and easier to read than
>
> 0644
>
> must be decided. I would saz no, it is not.
I was about to write the same thing.
I dislike magic numbers just like the next guy, but this replaces
a compact representation of the permissions with a long string of hard
to read, awkwardly abbreviated strings.
On personal note, I can never remember whether ‘u’ means user and ‘o’
means other or ‘u’ means users and ‘o’ means ‘owner’. In cited case
this is somehow averted because both USR and OTH are present, but what
does ‘S_IRWXU’ mean is a mystery to me.
To my mind, the macros make sense only when testing for particular bit
being set. Something like:
if (mode & S_IRUSR && check_if_user_can_read())
success;
could be argued as better than ‘mode & 0400’ but even than the awkward
abbreviation doesn’t help. Again, ‘PERM_USER_READABLE’ would be much
better (also for the reason mentioned above).
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
prev parent reply other threads:[~2016-08-03 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 12:05 [PATCH 0984/1285] Replace numeric parameter like 0444 with macro Baole Ni
2016-08-02 13:54 ` Felipe Balbi
2016-08-02 14:03 ` Marcel Holtmann
2016-08-02 14:04 ` Marcel Holtmann
2016-08-03 8:30 ` Oliver Neukum
2016-08-03 11:15 ` Michal Nazarewicz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xa1tpopqdrxl.fsf@mina86.com \
--to=mina86@mina86.com \
--cc=baolex.ni@intel.com \
--cc=chuansheng.liu@intel.com \
--cc=deepa.kernel@gmail.com \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=k.kozlowski@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=m.szyprowski@samsung.com \
--cc=mathias.nyman@linux.intel.com \
--cc=oneukum@suse.com \
--cc=peter.chen@freescale.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.