Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 1 Aug 2022 14:51:21 +0200
From:   Cyril Hrubis <chrubis@suse.cz>
To:     Petr Vorel <pvorel@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
Message-ID: <YufMST1r0+ciz2c4@yuki>
References: <20220729153246.1213-1-pvorel@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220729153246.1213-1-pvorel@suse.cz>
Precedence: bulk

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.

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_".

-- 
Cyril Hrubis
chrubis@suse.cz