All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: cocci@inria.fr
Cc: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Subject: [cocci] HELP: multiple inserts at one position
Date: Thu, 9 Mar 2023 09:28:12 +0100	[thread overview]
Message-ID: <20230309092812.71b25d5c@nbbrfq> (raw)

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

Hi!

I'm trying to follow Julias advise in
https://www.mail-archive.com/cocci@systeme.lip6.fr/msg06465.html
---8<---
> >   Unfortunately, I stumble on the error message “replacement: already 
> > tagged token:
> >   C code context” then.

This is what I would expect.  You could use one rule with an exists to put
a position variable in the place where you want to put a kfree, and then
use another rule to put a kfree at that position.
---8<---

I'm attaching my sample inp.c and my attempt at the script and would be
glad if you could give some guidance how to properly phrase the
replacement rule.

In effect, i want to insert *multiple* hunks, each hunk before the
respective single return statement.

TIA for your help or any pointers and cheers,

PS:
In case it matters, i'm using the debian package which is
  spatch version 1.1.1 compiled with OCaml version 4.13.1

The two attached scripts are identical, just
  sed -i -e s/mpz/mpfr/g
If i patch the mpfr part of inp.c, then all works like i would
envision, since there is just a single replacement to be done:

$ spatch --sp-file ~/mpfr_free.0.cocci /tmp/inp.cc;echo EOF
init_defs_builtins: /usr/lib/coccinelle/standard.h
HANDLING: /tmp/inp.cc
diff = 
--- /tmp/inp.cc
+++ /tmp/cocci-output-1395250-146bec-inp.cc
@@ -34,9 +34,11 @@ CompileExpr::compile_float_literal (cons
       rust_error_at (expr.get_locus (),
 		     "decimal overflows the respective type %<%s%>",
 		     tyty->get_name ().c_str ());
+      mpfr_clear(fval);
       return error_mark_node;
     }
 
+  mpfr_clear(fval);
   return real_value;
 }
 
EOF

But when attempting to insert multiple "free()" for a handful of
identifiers in the mpz case, then:
$ spatch --sp-file ~/mpz_free.0.cocci /tmp/inp.cc ; echo EOF
init_defs_builtins: /usr/lib/coccinelle/standard.h
HANDLING: /tmp/inp.cc
     
previous modification:

  <<< mpz_clear(i);
CONTEXT

According to environment 4:
   mpz_0_find.i -> id ival

   mpz_0_find.ret_pos -> poss[(/tmp/inp.cc,CompileExpr::compile_integer_literal,((44,0),(80,1)),(71,6),(71,12))]

   mpz_0_find.i -> id ival

   mpz_0_find.ret_pos -> poss[(/tmp/inp.cc,CompileExpr::compile_integer_literal,((44,0),(80,1)),(71,6),(71,12))]


current modification:

  <<< mpz_clear(i);
CONTEXT

According to environment 4:
   mpz_0_find.i -> id type_max

   mpz_0_find.ret_pos -> poss[(/tmp/inp.cc,CompileExpr::compile_integer_literal,((44,0),(80,1)),(71,6),(71,12))]

   mpz_0_find.i -> id type_max

   mpz_0_find.ret_pos -> poss[(/tmp/inp.cc,CompileExpr::compile_integer_literal,((44,0),(80,1)),(71,6),(71,12))]


mpz_0_replace: already tagged token:
C code context
File "/tmp/inp.cc", line 71, column 6, charpos = 1993
  around = 'return',
  whole content =       return error_mark_node;
EOF

Isn't this OK nevertheless?

[-- Attachment #2: inp.cc.txt --]
[-- Type: text/plain, Size: 2167 bytes --]

tree
CompileExpr::compile_float_literal (const HIR::LiteralExpr &expr,
				    const TyTy::BaseType *tyty)
{
  rust_assert (expr.get_lit_type () == HIR::Literal::FLOAT);
  const auto literal_value = expr.get_literal ();

  mpfr_t fval;
  if (mpfr_init_set_str (fval, literal_value.as_string ().c_str (), 10,
			 MPFR_RNDN)
      != 0)
    {
      rust_error_at (expr.get_locus (), "bad number in literal");
      mpfr_clears(expr, fval, NULL);
      mpfr_clear(fval);
      return error_mark_node;
    }

  tree type = TyTyResolveCompile::compile (ctx, tyty);

  // taken from:
  // see go/gofrontend/expressions.cc:check_float_type
  mpfr_exp_t exp = mpfr_get_exp (fval);
  bool real_value_overflow = exp > TYPE_PRECISION (type);

  REAL_VALUE_TYPE r1;
  real_from_mpfr (&r1, fval, type, GMP_RNDN);
  REAL_VALUE_TYPE r2;
  real_convert (&r2, TYPE_MODE (type), &r1);

  tree real_value = build_real (type, r2);
  if (TREE_OVERFLOW (real_value) || real_value_overflow)
    {
      rust_error_at (expr.get_locus (),
		     "decimal overflows the respective type %<%s%>",
		     tyty->get_name ().c_str ());
      return error_mark_node;
    }

  return real_value;
}


tree
CompileExpr::compile_integer_literal (const HIR::LiteralExpr &expr,
				      const TyTy::BaseType *tyty)
{
  rust_assert (expr.get_lit_type () == HIR::Literal::INT);
  const auto literal_value = expr.get_literal ();

  tree type = TyTyResolveCompile::compile (ctx, tyty);

  mpz_t ival;
  if (mpz_init_set_str (ival, literal_value.as_string ().c_str (), 10) != 0)
    {
      rust_error_at (expr.get_locus (), "bad number in literal");
      return error_mark_node;
    }

  mpz_t type_min;
  mpz_t type_max;
  mpz_init (type_min);
  mpz_init (type_max);
  get_type_static_bounds (type, type_min, type_max);

  if (mpz_cmp (ival, type_min) < 0 || mpz_cmp (ival, type_max) > 0)
    {
      rust_error_at (expr.get_locus (),
		     "integer overflows the respective type %<%s%>",
		     tyty->get_name ().c_str ());
      return error_mark_node;
    }

  tree result = wide_int_to_tree (type, wi::from_mpz (type, ival, true));

  mpz_clear (type_min);
  mpz_clear (type_max);

  return result;
}

[-- Attachment #3: mpfr_free.0.cocci.txt --]
[-- Type: text/plain, Size: 587 bytes --]

/// mpfr ///////////////////////////////////////////////////////////////

@ mpfr_0_find exists@
identifier i;
type mpfr_t;
position ret_pos;
@@
mpfr_t i;
...
(
mpfr_init_set_str (i, ...)
|
mpfr_init (i)
|
mpfr_init2 (i, ...)
|
mpfr_init3 (i, ...)
)
... when != mpfr_clear (i)
    when != mpfr_clears (...,i,...)
(
  return \(<+...i...+>\);
|
//Ideally i would prefer to just have this single rule and just do:
//+ mpfr_clear (i);
return@ret_pos ...;
)

@ mpfr_0_replace @
identifier mpfr_0_find.i;
//expression E;
position mpfr_0_find.ret_pos;
@@
+ mpfr_clear (i);
? return@ret_pos ...;

[-- Attachment #4: mpz_free.0.cocci.txt --]
[-- Type: text/plain, Size: 572 bytes --]

/// mpz ///////////////////////////////////////////////////////////////

@ mpz_0_find exists@
identifier i;
type mpz_t;
position ret_pos;
@@
mpz_t i;
...
(
mpz_init_set_str (i, ...)
|
mpz_init (i)
|
mpz_init2 (i, ...)
|
mpz_init3 (i, ...)
)
... when != mpz_clear (i)
    when != mpz_clears (...,i,...)
(
  return \(<+...i...+>\);
|
//Ideally i would prefer to just have this single rule and just do:
//+ mpz_clear (i);
return@ret_pos ...;
)

@ mpz_0_replace @
identifier mpz_0_find.i;
//expression E;
position mpz_0_find.ret_pos;
@@
+ mpz_clear (i);
? return@ret_pos ...;

             reply	other threads:[~2023-03-09  8:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09  8:28 Bernhard Reutner-Fischer [this message]
     [not found] ` <89959f1e-b5ed-6b2c-2931-4fdd65428e89@inria.fr>
2023-03-09  8:47   ` [cocci] HELP: multiple inserts at one position Julia Lawall
2023-03-09  9:10     ` Bernhard Reutner-Fischer
2023-03-09  9:38       ` Julia Lawall
2023-03-09 10:15         ` Bernhard Reutner-Fischer
2023-03-09 10:23           ` Julia Lawall
2023-03-10 10:01     ` Bernhard Reutner-Fischer
2023-03-10 10:12       ` Julia Lawall
2023-03-13 19:38         ` Bernhard Reutner-Fischer
2023-03-13 21:09           ` Julia Lawall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230309092812.71b25d5c@nbbrfq \
    --to=rep.dot.nop@gmail.com \
    --cc=cocci@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.