All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Richard Palethorpe <rpalethorpe@suse.com>,
	"ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH] mount03: Convert to new API
Date: Mon, 25 Jul 2022 10:52:34 +0200	[thread overview]
Message-ID: <Yt5Z0s6ymBfgUL4j@pevik> (raw)
In-Reply-To: <YtURQlBJhpnWoSCv@yuki>

> Hi!
> > @Richie @Li @Metan: There are checkpatch.pl warnings. Yes, kernel folks does not
> > like permission warnings. Do we want to follow? Or should we remove these from
> > our checkpatch.pl fork (we use constants in many places)?

> > $ make check-mount03
> > mount03.c:29: WARNING: Symbolic permissions 'S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH' are not preferred. Consider using octal permissions '0644'.
> > mount03.c:30: WARNING: Symbolic permissions 'S_IRUSR|S_IXUSR|S_IXGRP|S_IXOTH' are not preferred. Consider using octal permissions '0511'.
> > mount03.c:50: WARNING: static char array declaration should probably be static const char
> > mount03.c:103: WARNING: Symbolic permissions 'S_IRWXU' are not preferred. Consider using octal permissions '0700'.
> > mount03.c:114: WARNING: Symbolic permissions 'S_IRWXU' are not preferred. Consider using octal permissions '0700'.
> > mount03.c:125: WARNING: Symbolic permissions 'S_IRWXU' are not preferred. Consider using octal permissions '0700'.
> > mount03.c:181: WARNING: Symbolic permissions 'S_IRWXU' are not preferred. Consider using octal permissions '0700'.
> > mount03.c:204: WARNING: Symbolic permissions 'S_IRWXU' are not preferred. Consider using octal permissions '0700'.

> To be honest I think Linus is right at this one, the single octal number
> is way more readable than the bitwise or of four constants, so I would
> be inclined to start following the kernel practice here.

Agree with the rule, numbers are indeed much readable and I'm for using it in
LTP source.

My concern was different: aren't these constants part of POSIX? See man from
<sys/stat.h> from 1997 [1]. There might be a test for these constants but
it has much lower priority than tests for new kernel functionality and CVE.

Kind regards,
Petr

[1] https://pubs.opengroup.org/onlinepubs/007908799/xsh/sysstat.h.html

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2022-07-25  8:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15  6:25 [LTP] [PATCH] mount03: Convert to new API chenhx.fnst
2022-07-15 16:44 ` Petr Vorel
2022-07-18  7:14   ` Richard Palethorpe
2022-07-18  7:52   ` Cyril Hrubis
2022-07-25  8:52     ` Petr Vorel [this message]
2022-08-16  9:53       ` xuyang2018.jy
2022-07-26  6:12   ` [LTP] 回复: " chenhx.fnst

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=Yt5Z0s6ymBfgUL4j@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=rpalethorpe@suse.com \
    /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.