Linux NFS development
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it, linux-nfs@vger.kernel.org,
	Chen Hanxiao <chenhx.fnst@fujitsu.com>
Subject: Re: [RFC PATCH 1/1] metaparse: Replace macro also in arrays
Date: Mon, 1 Aug 2022 16:35:25 +0200	[thread overview]
Message-ID: <YufkrU5Z1GCsBhcU@pevik> (raw)
In-Reply-To: <YufMST1r0+ciz2c4@yuki>

> Hi!
> > This helps to replace macros like:

> >     #define TEST_APP "userns06_capcheck"

> >     static const char *const resource_files[] = {
> > 	TEST_APP,
> > 	NULL,
> >     };

> > $ ./metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ ../testcases/kernel/containers/userns/userns06.c
> > Before:
> >    "resource_files": [
> >      "TEST_APP"
> >     ],
> >     ...

> > After:
> >    "resource_files": [
> >      "userns06_capcheck"
> >     ],
> >     ...

> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Hi all,

> > This is a reaction on patch
> > https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@fujitsu.com/
> > First: I was wrong, inlining arrays does any change in the docparse output.
> > BTW I'd be still for inlining for better readability.

> > I'm not sure if this is not good idea, maybe some of the constants should be
> > kept unparsed, e.g.:

> > Orig:
> >    "caps": [
> >      "TST_CAP",
> >      "(",
> >      "TST_CAP_DROP",
> >      "CAP_SYS_RESOURCE",

> > Becomes:
> >    "caps": [
> >      "TST_CAP",
> >      "(",
> >      "TST_CAP_DROP",
> >      "24",

> > CAP_SYS_RESOURCE is replaced because it's a string, but IMHO it'd be better to keep it.
> > TST_CAP{_DROP,} aren't replaced because they aren't a plain strings.
> > Maybe replace only non-numerc values?

> That really depends on the context, we do have many cases where we have
> a macro that expands to numeric that should be expanded, runtime would
> be one of the prime examples of that.
Yep.

> I guess that the only solution would be an explicit list of macro
> prefixes that should not be expanded, e.g. do not expand if macro starts
> with "CAP_".

Good idea, thanks! I was thinking about rewrite parsing to sparse, but you would
not like it as being slow. This is indeed a better solution.

Kind regards,
Petr

      reply	other threads:[~2022-08-01 14:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 15:32 [RFC PATCH 1/1] metaparse: Replace macro also in arrays Petr Vorel
2022-08-01 12:51 ` Cyril Hrubis
2022-08-01 14:35   ` Petr Vorel [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=YufkrU5Z1GCsBhcU@pevik \
    --to=pvorel@suse.cz \
    --cc=chenhx.fnst@fujitsu.com \
    --cc=chrubis@suse.cz \
    --cc=linux-nfs@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox