On Wed, 22 Apr 2020, Markus Elfring wrote:
> Hello,
>
> I have taken another look at the following information.
> https://github.com/coccinelle/coccinelle/blob/6b4bb692f208bfe86e62a616724570d9310c7150/standard.iso#L544
>
> …
> // Affectation/initialisation isomorphism
> …
> // They are handled
On Sat, 18 Apr 2020, Tiezhu Yang wrote:
> When I use coccicheck, it fails with the message "spatch is part of the
> Coccinelle project and is available at http://coccinelle.lip6.fr/;, but
> I can not download the source code of spatch due to the URL [1] was not
> found on this server.
>
> Use
On Thu, 16 Apr 2020, Markus Elfring wrote:
> >> Would I need any extra parameters here?
> >
> > Perhaps -I options to help it find the relevant .h file.
>
> I wonder why the relevant header files would not be found directly
> from the corresponding Git repository.
OK, it seems that the
On Thu, 16 Apr 2020, Markus Elfring wrote:
> >> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
> >> --include-headers-for-types
> >> ~/Projekte/Coccinelle/janitor/use_devm_platform_get_and_ioremap_resource3.cocci
> >> drivers/i2c/busses/i2c-rcar.c
> >
> > No, include headers for types
On Thu, 16 Apr 2020, Markus Elfring wrote:
> >> @replacement@
> >> expression* base, device, resource;
> >> @@
> >> -resource = platform_get_resource(device, IORESOURCE_MEM, 0);
> >> base =
> >> - devm_ioremap_resource(>dev, resource)
> >> +
On Wed, 15 Apr 2020, Markus Elfring wrote:
> Hello,
>
> I noticed the suggestion “i2c: busses: convert to
> devm_platform_get_and_ioremap_resource”.
> https://lore.kernel.org/linux-i2c/20200414134827.18674-1-zhengdej...@gmail.com/
> https://lore.kernel.org/patchwork/patch/1223734/
>
> I got
On Mon, 13 Apr 2020, Markus Elfring wrote:
> >> I would find it nice to explain the different software behaviour for the
> >> mentioned
> >> SmPL code variants
> >
> > Run spatch -parse-cocci and you will easily see. The if stays in the same
> > place. When the isomorphism exchanges the
On Mon, 13 Apr 2020, Markus Elfring wrote:
> >>> Maybe you consider the following results to be a problem:
> >>>
> >>> kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> >>> kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> >>> platform_get_irq irq
On Mon, 13 Apr 2020, Markus Elfring wrote:
> > Maybe you consider the following results to be a problem:
> >
> > kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> > kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> > platform_get_irq irq [("mcde_probe", 2,
I tried the following semantic patches:
@find@
expression action, check, result;
position p;
statement is, es;
@@
result = action(...);
if (
( <+... result ...+>
& check@p
) )
is
else
es
@script:ocaml@
action << find.action;
check << find.check;
p << find.p;
@@
Printf.printf "%s
On Sun, 12 Apr 2020, Markus Elfring wrote:
> @display2@
> expression check;
> position display1.p;
> statement display1.is, display1.es;
> >>>
> >>> The problem is that you inherit es. Since you inherit it, Coccinelle
> >>> considers that its presence is important, and so
On Sun, 12 Apr 2020, Markus Elfring wrote:
> >> I hope that another clarification can be achieved also for the software
> >> behaviour of the following source code analysis approach.
> >
> > I don't run code that involves databases. If you believe that there is a
> > problem with the semantic
On Sun, 12 Apr 2020, Markus Elfring wrote:
> >> I hope that another clarification can be achieved also for the software
> >> behaviour of the following source code analysis approach.
> >
> > I don't run code that involves databases.
>
> Can the situation evolve in a way so that this
On Sat, 11 Apr 2020, Markus Elfring wrote:
> > Maybe you can just take inspiration from this paper:
> >
> > https://pages.lip6.fr/Julia.Lawall/dsn09.pdf
>
> I got another idea which can be related to information from the section
> “Case Study: Inconsistent Error Checks” in your document
On Fri, 10 Apr 2020, Markus Elfring wrote:
> Hello,
>
> Several functions for a programming language like C are designed in the way
> that values are returned by an integral data type.
> Specific value ranges can indicate then a failed function call.
> A well-known variant of this design pattern
> >> kthread_stop@stop_p(...)
> >> ...
> >> mutex_lock@lock_p(E)
> >>
> >> @script:python@
> >> stop_p << race.stop_p;
> >> unlock_p << race.unlock_p;
> >> lock_p << race.lock_p;
> >> E << race.E;
> >> @@
> >>
> >> coccilib.report.print_report(unlock_p[0], 'mutex_unlock(' + E + ') here')
> >>
On Thu, 9 Apr 2020, Alexander Popov wrote:
> Hello!
>
> Some time ago I fixed CVE-2019-18683 in the V4L2 subsystem of the Linux
> kernel.
>
> I created a Coccinelle rule that detects that bug pattern. Let me show it.
Thanks for the discussion :)
>
>
> Bug pattern
> ===
>
>
On Fri, 3 Apr 2020, Alex Dewar wrote:
> Commit dfd32cad146e ("dma-mapping: remove dma_zalloc_coherent()"), in
> removing dma_zalloc_coherent() treewide, inadvertently removed the patch
> rule for dma_alloc_coherent(), leaving Coccinelle unable to auto-generate
> patches for this case. Fix
On Tue, 31 Mar 2020, Joe Perches wrote:
> On Tue, 2020-03-31 at 10:50 +0200, Julia Lawall wrote:
> > On Mon, 30 Mar 2020, Joe Perches wrote:
> >
> > > There is a block of if tests against the same variable
> > > in include/linux/mt
On Mon, 30 Mar 2020, Joe Perches wrote:
> There is a block of if tests against the same variable
> in include/linux/mtd/pfow.h that likely is defective
>
> if (prog_status & 0x3)
> ...
> else if (prog_status & 0x2)
> ...
> else
On Mon, 30 Mar 2020, Markus Elfring wrote:
> >> …
> >> (ONCE) CPP-MACRO: found known macro = FNAME
> >> …
> >> parse error
> …
> >> How would you like to improve the affected software areas?
> >
> > This can be addressed by adding a macro definition to standard.h.
>
> A corresponding
On Mon, 30 Mar 2020, Markus Elfring wrote:
> >> How will corresponding software development resources evolve?
> >
> > I don't think I understand the question, or, actually, are you asking
> > me or the coccinelle developers ?
>
> I hope that more development challenges will be picked up.
>
>
On Sun, 29 Mar 2020, Christoph Böhmwalder wrote:
> Am 29.03.20 um 11:20 schrieb Julia Lawall>
> > It's not parsing anything. You can see that here. It is passing, ie
> > ignoring, the entire command line.
>
> Right, I misinterpreted that "passed"
On Sun, 29 Mar 2020, Christoph Böhmwalder wrote:
> Am 27.03.20 um 17:15 schrieb Julia Lawall:
> >
> >
> > On Fri, 27 Mar 2020, Christoph Böhmwalder wrote:
> >
> > > Am 27.03.20 um 16:47 schrieb Julia Lawall:> Are you sure that the C code
> > > is
On Sat, 28 Mar 2020, Markus Elfring wrote:
> > I have this all working with the following script with the caveat that
> > running it on moderately complicated source files makes it never
> > finish (after an hour or so the spatch process crashes with a stack
> > overflow error).
>
> Do you
> // deleted part
> retry:
> down_read(>mmap_sem);
> vma = find_vma(mm, address);
> if (!vma)
> goto bad_area;
> // deleted part
> }
> // deleted part
>
>
> Application of the software “Coccinelle 1.0.8-00029-ga549b9f0” (OCaml 4.10.0)
>
>
On Sat, 28 Mar 2020, Markus Elfring wrote:
> >> How will corresponding software development resources evolve?
> >
> > I don't think I understand the question, or, actually, are you asking
> > me or the coccinelle developers ?
>
> I hope that another communication approach can eventually
On Sat, 28 Mar 2020, Markus Elfring wrote:
> >> How will corresponding software development resources evolve?
> >
> > I don't think I understand the question, or, actually, are you asking
> > me or the coccinelle developers ?
>
> I hope that another communication approach can eventually
On Fri, 27 Mar 2020, George McCollister wrote:
> Hello,
>
> I'm working with an old code base that makes excessive use of the
> following sort of construct:
>
> char display[128];
>
> ...
>
> snprintf(display, sizeof(display), "example log message %d", i);
> log_buffer(level,
On Fri, 27 Mar 2020, Christoph Böhmwalder wrote:
> Am 27.03.20 um 16:47 schrieb Julia Lawall:> Are you sure that the C code is
> parsed successfully? I'm not at all sure
> > that static is allowed in an argument list. Types are allowed, bu static
> > is only part of a
On Fri, 27 Mar 2020, Christoph Böhmwalder wrote:
> Hi again,
>
> I'm having a little trouble matching against this line of code:
>
> RB_DECLARE_CALLBACKS_MAX(static, augment_callbacks, struct
> drbd_interval, rb, sector_t, end, NODE_END);
>
> This is especially tricky because it contains a lot
On Wed, 25 Mar 2020, Markus Elfring wrote:
> Hello,
>
> I have noticed the patch “tty: serial: fsl_lpuart: fix return value checking”.
> https://lore.kernel.org/linux-serial/20200325090658.25967-2-mich...@walle.cc/
> https://lore.kernel.org/patchwork/patch/1215542/
>
On Thu, 19 Mar 2020, Jaskaran Singh wrote:
> On Thu, 2020-03-19 at 16:54 +0100, Julia Lawall wrote:
> >
> > On Thu, 19 Mar 2020, Jaskaran Singh wrote:
> >
> > > On Wed, 2020-03-18 at 18:25 +0100, Julia Lawall wrote:
> > > > On Mon, 16 Mar 2020, Jask
On Thu, 19 Mar 2020, Jaskaran Singh wrote:
> On Wed, 2020-03-18 at 18:25 +0100, Julia Lawall wrote:
> >
> > On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> >
> > > To add the types ParenType and FunctionType to the SmPL AST, a
> > > reduce/reduce conflict wi
On Thu, 19 Mar 2020, Jaskaran Singh wrote:
> On Wed, 2020-03-18 at 18:31 +0100, Julia Lawall wrote:
> >
> > On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> >
> > > The direct_declarator rule and the direct_abstract_d rule are
> > > present in the C parser.
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> Add a test case to match against an array of function pointers.
> This would previously not work due to differences in the C
> and SmPL ASTs.
>
Thanks for all of the changes in this series!
julia
> Signed-off-by: Jaskaran Singh
> ---
>
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> The order of the terms in ParenType require implementing a special
> case for ParenType. This case handles only the following:
>
> ( * id [ .* ] ) ( params )
>
> i.e., a function pointer or an array of function pointers, and will fail
> for
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> The order of the terms in ParenType require implementing a special
> case for ParenType. This case handles only the following:
>
> ( * id [ .* ] ) ( params )
>
> i.e., a function pointer or an array of function pointers, and will fail
> for
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> ParenType and FunctionType are now added to the SmPL ASTs. Add
> cases for these types in compute_lines.ml.
>
> Signed-off-by: Jaskaran Singh
> ---
> parsing_cocci/compute_lines.ml | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> ParenType and FunctionType are now added to the SmPL ASTs. Add
> cases for these types in adjust_pragmas.ml.
>
> Signed-off-by: Jaskaran Singh
> ---
> parsing_cocci/adjust_pragmas.ml | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> ParenType/FunctionType are now types in the SmPL ASTs. Add
> cases for these types in single_statement.ml.
>
> Signed-off-by: Jaskaran Singh
> ---
> parsing_cocci/single_statement.ml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> ParenType/FunctionType are now types in the SmPL ASTs. Add
> cases for these types in unparse_ast0.ml.
>
> Signed-off-by: Jaskaran Singh
> ---
> parsing_cocci/unparse_ast0.ml | 43 +++
> 1 file changed, 43
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> ParenType and FunctionType are now added to the SmPL ASTs. Add
> cases for these types in index.ml.
>
> Signed-off-by: Jaskaran Singh
> ---
> parsing_cocci/index.ml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/parsing_cocci/index.ml
On Tue, 17 Mar 2020, Jaskaran Singh wrote:
> The order of the terms in ParenType require implementing a special
> case for ParenType. This case handles only the following:
>
>( * id [ .* ] ) ( params )
>
> i.e., a function pointer or an array of function pointers, and will fail
> for
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> The order of the terms in ParenType require implementing a special
> case for ParenType. This case handles only the following:
>
>( * id [ .* ] ) ( params )
>
> i.e., a function pointer or an array of function pointers, and will fail
> for
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> The direct_declarator rule and the direct_abstract_d rule are
> present in the C parser. Add similar rules to the SmPL parser so that
> declarators are parsed as they are in the C parser.
>
> For the type ParenType, direct_declarator and
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> ParenType and FunctionType are types present in the C AST that
> are not present in the SmPL AST. In the pursuit of aligning
> both the C and SmPL ASTs, add these types to the SmPL ASTs.
It would be nice to extend the log message to give an example
On Mon, 16 Mar 2020, Jaskaran Singh wrote:
> To add the types ParenType and FunctionType to the SmPL AST, a
> reduce/reduce conflict with the funproto rule of the SmPL parser
> must be resolved. This requires explicitly identifying a function
> prototype by use of a token (TFunProto).
>
>
On Tue, 17 Mar 2020, Markus Elfring wrote:
> >> How do you think about to combine such changes in a bigger update step?
> >
> > These are separated this way so that it's easier for Julia to review.
>
> I suggest to reconsider such an approach.
>
>
> > She will probably just squash all 26 of
On Tue, 17 Mar 2020, Jaskaran Singh wrote:
> The order of the terms in ParenType require implementing a special
> case for ParenType. This case handles only the following:
>
>( * id [ .* ] ) ( params )
>
> i.e., a function pointer or an array of function pointers, and will fail
> for
On Wed, 11 Mar 2020, Markus Elfring wrote:
> >> ... when any
> >> when != pointer = \( action(...) \| x \)
> >> *if (
> >> (!pointer
> >> |pointer == NULL
> >> )
> >
> > pointer == NULL would have been sufficient (not related to the noted
> > problems).
>
> Should this detail be
On Sun, 8 Mar 2020, Jaskaran Singh wrote:
> The C AST and SmPL AST differs with respect to the enum type.
>
> For an enumerator, the C AST is as follows:
> Enum -> list of (name, (info, expression))
>
> For the same, the SmPL AST is as follows:
> EnumDef -> list of expression
>
> While
On Sun, 8 Mar 2020, Markus Elfring wrote:
> Hello,
>
> I have tried the following small script variant out again for
> the semantic patch language.
>
> @display@
> expression action;
> expression* pointer, target, x;
> identifier member, var;
> statement is;
> type t;
> @@
> (
> *t* var =
occinelle.
The files are gone in github. We expect to make a new release within
about a week.
julia
>
>
>
> On Thu, Feb 27, 2020 at 7:04 AM Julia Lawall wrote:
>
>
> On Thu, 27 Feb 2020, Nicolas Palix wrote:
>
> > Le 27/02/2020 à 10:45, Julia Lawall a éc
On Thu, 27 Feb 2020, Nicolas Palix wrote:
> Le 27/02/2020 à 10:45, Julia Lawall a écrit :
> >
> >
> > On Thu, 27 Feb 2020, Nicolas Palix wrote:
> >
> > > Hi Emmanuel,
> > >
> > > Instead of porting to GObject directly,
> > > can w
ry. I don't think that that python file is useful.
julia
>
> Regards,
>
> Le 04/02/2020 à 16:25, eamanu a écrit :
> > Hi!
> >
> > On 04/02/2020 11:59, Julia Lawall wrote:
> > > On Tue, 4 Feb 2020, eamanu wrote:
> > >
> > > > Hi everybod
--- Please note the new email address ---
On Wed, 19 Feb 2020, Ville Syrjälä wrote:
> Hi all,
>
> I was trying to do the following transformation:
> @@
> identifier M;
> expression E;
> @@
> - struct foo M = E;
> + struct foo M;
> + copy_struct(, );
>
> but without inserting the function call
On Tue, 11 Feb 2020, Jaskaran Singh wrote:
> This series is to address the type matching problem in Coccinelle.
>
> Patch 1/3 is for aligning the C and Cocci AST so that
> pointer to const pointer and its variants can be matched.
>
> Patch 2/3 reflects the pretty printing changes made in
> 1/3 in
On Sun, 9 Feb 2020, Jaskaran Singh wrote:
> On Sun, 2020-02-09 at 17:48 +0100, Julia Lawall wrote:
> > On Sun, 9 Feb 2020, Jaskaran Singh wrote:
> >
> > > Pointer to const pointer and its variants would not match
> > > previously.
> > >
On Sun, 9 Feb 2020, Jaskaran Singh wrote:
> Pointer to const pointer and its variants would not match previously.
> Add a test case for matching these types.
>
> Signed-off-by: Jaskaran Singh
> ---
> tests/constptr.c | 7 +++
> tests/constptr.cocci | 19 +++
>
On Sun, 9 Feb 2020, Jaskaran Singh wrote:
> For a pointer, the C parser constructed an AST dissimilar from that
> of the Cocci AST. This caused failures in matching with certain
> pointer types. For example, for the following case:
>
> char *1 const *2 id;
>
> The C AST constructed would be:
>
On Sun, 9 Feb 2020, Jaskaran Singh wrote:
> For a pointer, the C parser constructed an AST dissimilar from that
> of the Cocci AST. This caused failures in matching with certain
> pointer types. For example, for the following case:
>
> char *1 const *2 id;
>
> The C AST constructed would be:
>
On Sun, 9 Feb 2020, Markus Elfring wrote:
> > For a pointer, the C parser constructed an AST dissimilar from that
>
> I find it helpful to mention the meaning of the term “AST” without
> abbreviation
> for a nicer patch description.
> https://en.wikipedia.org/wiki/AST
Not necessary. Anyone who
On Sun, 9 Feb 2020, Markus Elfring wrote:
> > Like what?
>
> Do find my corresponding previous suggestion reasonable?
> https://lore.kernel.org/cocci/702596c2-84bf-13ca-b014-8784bbb98...@web.de/
> https://systeme.lip6.fr/pipermail/cocci/2020-February/006842.html
I have absolutely no preference
On Sun, 9 Feb 2020, Markus Elfring wrote:
> > This series is to address …
>
> Under which circumstances would you choose an adjusted wording for the message
> in the cover letter?
Like what?
If you are referring to something that occurs 5 lines below what you have
quoted, please include the
On Sun, 9 Feb 2020, Jaskaran Singh wrote:
> On Sun, 2020-02-09 at 08:20 +0100, Julia Lawall wrote:
> > On Fri, 7 Feb 2020, Jaskaran Singh wrote:
> >
> > > Pointer to const pointer and its variants would not match
> > > previously.
> > > Add a test case
On Fri, 7 Feb 2020, Jaskaran Singh wrote:
> Pointer to const pointer and its variants would not match previously.
> Add a test case for matching these types.
I don't get any matches for this test. If I split the semantic patch into
four separate rules, then I get the change for id2 and id4, but
There is a problem with the pretty printing. For the following semantic
patch:
@@
type t;
symbol x;
@@
void main() {
- t x;
+ t y;
}
and the following C code:
void main() {
const char * const * x;
}
The output is:
void main() {
- const char * const * x;
+
On Fri, 7 Feb 2020, Pan Nengyuan wrote:
> Hello,
>
> I have an example:
>
> @@ expression d,p; @@
>
> - g_autoptr(d) p;
> + g_autoptr(d) p = NULL;
>
> C source code:
>
> void f(void)
> {
> g_autoptr(Test) *p1;
> }
>
> Then I got this error:
> minus: parse error:
On Thu, 6 Feb 2020, Jaskaran Singh wrote:
> On Wed, 2020-02-05 at 19:55 +0100, Markus Elfring wrote:
> > Would you like to avoid any abbreviations in the patch subject?
> >
>
> I used abbreviations to keep the patch subject short but still clear.
>
> Would the following be a better subject?
>
On Tue, 4 Feb 2020, eamanu wrote:
> Hi everybody,
>
> Sorry if this issues is duplicated, I am new in the mailing list
> and in a very quickly searching I didn't found about this issue.
>
> I am working on Coccinelle package on Debian
Thanks!
> and currently
> exist the next bug [1].
>
> There
On Tue, 4 Feb 2020, Markus Elfring wrote:
> >> @replacement@
> >> constant c;
> >> identifier text;
> >> statement is, es;
> >> @@
> >> <+...
> >
> > What is thhe point of the outer <+... ...+>?
>
> I would like to stress the possibility that source code adjustments
> can be performed
On Tue, 4 Feb 2020, Markus Elfring wrote:
> > The strcmp output has to be compared to zero strcmp(src_name,
> > "equalizer_input_level") == 0.
>
> Would you like to let the following script for the semantic patch language
> perform any changes in your source files automatically?
>
>
On Tue, 4 Feb 2020, Markus Elfring wrote:
> >>
> >> https://github.com/wwmm/pulseeffects/blob/acb5161a6ab8d3b0c395ed2809d3318ccf4931bc/src/source_output_effects.cpp#L6
> >
> > I guess it would be fine if you put
> >
> > typedef auto;
> >
> > among the metavariables?
>
> I would like to
On Tue, 4 Feb 2020, Markus Elfring wrote:
> >> @replacement@
> >> @@
> >> -auto
> >> +my_type
> >
> > There is nothing to support this.
>
> Thanks for such feedback.
>
>
> > So far I don't have the impression that anyone has had a need for it either.
>
> How often will I be the first one who
On Tue, 4 Feb 2020, Markus Elfring wrote:
> > I think it expects a type as well. I don't know if that is a reasonable
> > assumption in C or in C++.
>
> Can a source code transformation approach like the following make sense?
>
> @replacement@
> @@
> -auto
> +my_type
There is nothing to
On Tue, 4 Feb 2020, Markus Elfring wrote:
> >> Do you distinguish between the storage class specifier
> >> and other uses of such a key word?
> >> https://en.cppreference.com/w/cpp/language/auto
> >
> > Sorry. I know nothing about C++.
>
> I guess that you know something also for this
On Mon, 3 Feb 2020, Markus Elfring wrote:
> > Where is the space that yoyu are concerned about?
>
> …
> @@ -1,7 +1,7 @@
> void on_message_element …
> ↑
>
> How was this character added at the first column in this line
> of my software test approach?
I don't understand. If you are showing a
On Mon, 3 Feb 2020, Markus Elfring wrote:
> > Where is the space that yoyu are concerned about?
>
> …
> @@ -1,7 +1,7 @@
> void on_message_element …
> ↑
>
> How was this character added at the first column in this line
> of my software test approach?
>
>
> >>
> >>
On Mon, 3 Feb 2020, Markus Elfring wrote:
> Hello,
>
> I have tried the following small script variant out for
> the semantic patch language.
>
> @replacement@
> constant c;
> identifier text;
> expression x;
> statement is, es;
> @@
> char* text = x(...);
>
> if (
> + strcmp(
> text
> +
On Tue, 21 Jan 2020, Jaskaran Singh wrote:
> This patch series is for improving the management of the following
> case:
>
>
>
> If is a known typedef (such as u8 or *_t) then label as a
> CppMacro. Subsequent cases will continue to label correctly as a
> typedef identifier.
>
> Also add
On Tue, 21 Jan 2020, Jaskaran Singh wrote:
> On Tue, 2020-01-21 at 11:10 +0100, Markus Elfring wrote:
> > > Before:
> > > passed:bool
> >
> > I wonder if subsequent duplicate information can really help to
> > achieve a better understanding
> > by the suggested description of a software
On Tue, 21 Jan 2020, Markus Elfring wrote:
> > If is a known typedef (such as u8 or *_t) then label
> > as a CppMacro. Subsequent cases will label correctly as a
> > typedef ident.
> >
> > Also add bool to the list of known typedefs so that cases of
>
> Can a wording like the following be
On Tue, 21 Jan 2020, Jaskaran Singh wrote:
> On Tue, 2020-01-21 at 06:20 +0000, Julia Lawall wrote:
> >
> > On Sun, 19 Jan 2020, Jaskaran Singh wrote:
> >
> > > bool is widely used in the Linux kernel. Certain cases of
> > > parsing_hacks.ml wo
On Sun, 19 Jan 2020, Jaskaran Singh wrote:
> For the following case:
>
>
>
> A case in parsing_hacks.ml sometimes mislabels as a
> typedef ident.
>
> If typedef is a known typedef (such as u8 or *_t), then label
> as a CppMacro. Subsequent cases will then label
> correctly.
OK, I see
On Sun, 19 Jan 2020, Jaskaran Singh wrote:
> bool is widely used in the Linux kernel. Certain cases of
> parsing_hacks.ml would mislabel bool.
>
> Add bool to the list of known typedefs.
As far as I can see, this function is only used for avoiding to print some
warning messages. So I'm not
On Sun, 19 Jan 2020, Jaskaran Singh wrote:
> bool is widely used in the Linux kernel. Certain cases of
> parsing_hacks.ml would mislabel bool.
>
> Add bool to the list of known typedefs.
>
> Stats of --parse-c on Linux v5.5-rc4 are as follows:
>
> Before:
>
> nb good = 18956150, nb passed =
On Thu, 16 Jan 2020, Jaskaran Singh wrote:
> Previously, a space would not be added after the * const. Add
> a test case for testing spacing with use of the type.
>
> Signed-off-by: Jaskaran Singh
Applied, thanks.
julia
> ---
> tests/ptrconstptr.c | 3 +++
> tests/ptrconstptr.cocci |
On Thu, 16 Jan 2020, Jaskaran Singh wrote:
> On Thu, 2020-01-16 at 11:40 +0100, Markus Elfring wrote:
> > > In certain cases, there is no space added after the Pointer type.
> >
> > Will such a pretty-printing detail matter also for the clarification
> > of
> > a topic like “Make change
On Thu, 16 Jan 2020, Jaskaran Singh wrote:
> In certain cases, there is no space added after the Pointer type.
> Examples of such cases are * const, * __attr and * const *.
>
> In the Pointer case of pp_type_with_ident_rest and pp_type_left, if
> the * is followed by anything within the type,
On Wed, 15 Jan 2020, Oleg Nesterov wrote:
> On 01/15, Julia Lawall wrote:
> >
> > On Wed, 15 Jan 2020, Oleg Nesterov wrote:
> >
> > > $ spatch --sp-file test.cocci test.c
> > >
> > > (ONCE) Expected tokens mem TTT
> > > Skipping: te
On Wed, 15 Jan 2020, Oleg Nesterov wrote:
> On 01/15, Oleg Nesterov wrote:
> >
> > Another question...
>
> Oh, and another one ;)
>
> http://coccinelle.lip6.fr/docs/main_grammar006.html mentions
> "typeof(expr/ctype)", but I failed to find any doc/example of
> how can it be used in SPL.
>
>
On Wed, 15 Jan 2020, Oleg Nesterov wrote:
> On 01/15, Julia Lawall wrote:
> >
> > Yes, it doesn't currently understand typeof. If it's a big problem, it
> > should be easy to fix.
>
> OK, thanks Julia.
>
> Another question...
>
> inc.h:
>
>
On Wed, 15 Jan 2020, Oleg Nesterov wrote:
> Hello,
>
> trivial example:
>
> @r@
> int x;
> @@
>
> * x = 0;
>
> C code:
>
> void f(void)
> {
> int a;
> __typeof__(a) b;
>
> a = 0; // this matches
>
On Mon, 13 Jan 2020, Timur Tabi wrote:
> On Mon, Jan 13, 2020 at 5:04 PM Julia Lawall wrote:
> >
> > It might be possible to use
> >
> > @@
> > identifier a,b;
> > fresh identifier x = a ## "_" ## b;
> > @@
> >
>
On Mon, 13 Jan 2020, Timur Tabi wrote:
> On Mon, Jan 13, 2020 at 4:33 PM Julia Lawall wrote:
> >
> > Sorry, I don't follow what you are trying to do here. Could you send an
> > example of the desired before after C code? I see what you have above,
> > but
On Mon, 13 Jan 2020, Timur Tabi wrote:
> I don't know how to properly describe what I'm trying to do, so I'll
> just show an example.
>
> The code I'm working on has dozens of annoying macros that concatenate
> parameters into strings. For example,
>
> #define DRF_DEF(d,r,f,c) \
>
On Sun, 12 Jan 2020, Markus Elfring wrote:
> > This semantic patch is inspired by Mateusz Guzik's patch:
>
> Does such a wording mean also that you would like to support the operation
> mode “patch”
> by this SmPL script?
I see no reason why such a wording would imply such a thing.
z Guzik's patch:
> commit b0ab99e7736a ("sched: Fix possible divide by zero in avg_atom()
> calculation")
>
> Signed-off-by: Wen Yang
Acked-by: Julia Lawall
This looks good to me.
A small detail is that you don't need the parentheses in:
@r depends on (org || report)@
ju
> > +*do_div(f, \( l \| ul \| ul64 \| sl64 \) );
> >
> > We agree with Julia:
> > I don't se any point to this.
>
> Can the avoidance of duplicate source code (according to SmPL disjunctions)
> trigger positive effects on run time characteristics and software maintenance?
Markus. Please stop
401 - 500 of 2189 matches
Mail list logo
