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