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@xxxxxxx>
> ---
> Hi all,
>
> This is a reaction on patch
> https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@xxxxxxxxxxx/
> 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@xxxxxxx
