This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Support || and && in preprocessor's conditions.


On 06/20/2009 06:17 AM, Przemyslaw Pawelczyk wrote:
> ---
>  parse.cxx |   30 ++++++++++++++++++++++++++++--
>  1 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/parse.cxx b/parse.cxx
> index a26d594..a74b513 100644
> --- a/parse.cxx
> +++ b/parse.cxx
> @@ -332,16 +332,42 @@ parser::scan_pp (bool wildcard)
>  
>        // Do not evaluate the condition if we haven't expanded everything.
>        // This may occur when having several recursive conditionals.
> -      bool result = eval_pp_conditional (session, l, op, r);
> +      bool and_result = eval_pp_conditional (session, l, op, r);
>        delete l;
>        delete op;
>        delete r;
>  
> +      bool result = false;
> +      const token *n;
> +      while ((n = input.scan ()) && n->type == tok_operator)
> +        {
> +          if (n->content == "||")
> +            {
> +              result |= and_result;
> +              and_result = true;
> +            }
> +          else if (n->content != "&&")
> +            break;
> +          l = input.scan (false);
> +          op = input.scan (false);
> +          r = input.scan (false);
> +          if (l == 0 || op == 0 || r == 0)
> +            throw parse_error ("incomplete condition after '%('", t);
> +
> +          and_result &= eval_pp_conditional (session, l, op, r);
> +          delete l;
> +          delete op;
> +          delete r;
> +          delete n;
> +        }
> +
> +      result |= and_result;

The approach looks ok, but I would like to see less code duplication.
This might work better as a do-while loop, and it may also help to push
the scan/delete of (l,op,r) into eval_pp_conditional.

We need testcases for this too.  I don't think runtime tests are
necessary -- just semok and semko tests are probably fine, stuff like:

probe %( kernel_v > "99" || arch != "foo" %? begin %: badprobe %) {}

Note that *ok tests can be bundled together, but *ko tests must have
only one failure per test file.

It would also be nice if you could survey the tapsets and patch up
pieces to use these conditionals.  For example, the probe
scheduler.ctxswitch has redundancies that could be eliminated.

Thanks,

Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]