[DTrace-devel] [PATCH 04/12] Fix the -xcpp option

[Kris Van Hees]

On Fri, Jul 15, 2022 at 07:37:17PM -0700, Eugene Loh via DTrace-devel wrote:
> First of all, sorry for screwing up the Reply-to: stuff.  A number of posted
> patches never appeared in my inbox.  So I'm posting my reviews as fresh
> email threads in those cases.
> 
> For this one:
>     Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
> since it's good enough as is.
> 
> Nonetheless, I wanted to run an alternative by you.  If I understand
> correctly, we want dtrace options -C and -xcpp to be exactly the same
> thing.  So why not make them the same thing "at inception" rather than
> carrying them around separately and then trying to make them equivalent at
> the point of usage?
> 
> That is, how about replacing this patch with a "one-line" fix?  In
> cmd/dtrace.c, in the -x processing, add the statement:
>         if (strcmp(optarg, "cpp") == 0)
>                 g_cflags |= DTRACE_C_CPP;
> I think that eliminates the need for the DTRACE_C_DLIB stuff.  I understand
> there is something a little weird about doing this in the -x processing, but
> the reality is that the weirdness is dtrace's way of handling these options
> -- the proposed addition is simply the most direct way of dealing with this.

The thing is that cmd/dtrace.c is the default front-end for libdtrace, and
options like -C and -S are cmd/dtrace options.  The -x<opt> options are
lindtrace options, i.e. options that can be set through the API that libdtrace
provides.  Therefore, processing them in cmd/dtrace.c would break that entire
design.

I'd say that cmd/dtrace could probably be modified to actually use the
libdtrace API rather than passing in flags in an entirely different way, but
that seems to be something that has a larger scope and would best be done with
a separate patch series that reworks the cflags handling.  For now, the point
is to make the option work which is what this point does.