[Cocci] macro parameters and expressions?

[Cocci] macro parameters and expressions?

[Jürgen Groß]

Hi,

I have a simple semantic patch:

   virtual patch

   @@
   expression buf, val;
   @@
   - snprintf(buf, PAGE_SIZE, "%d\n", val)
   + spgprintf_d(buf, val)

This works nearly always as expected, but not in some macros. The cases
where it is not working are those when "val" is using a parameter of the
macro, e.g.:

   #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)

Is that on purpose? If yes, how can this be avoided?


Juergen
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Julia Lawall]

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



On Fri, 11 Oct 2019, Jürgen Groß wrote:

> Hi,
>
> I have a simple semantic patch:
>
>   virtual patch
>
>   @@
>   expression buf, val;
>   @@
>   - snprintf(buf, PAGE_SIZE, "%d\n", val)
>   + spgprintf_d(buf, val)
>
> This works nearly always as expected, but not in some macros. The cases
> where it is not working are those when "val" is using a parameter of the
> macro, e.g.:
>
>   #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
>
> Is that on purpose? If yes, how can this be avoided?

I don't think it should be on purpose.  Could you send some C code that
illustrates the problem?

thanks,
julia

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

>    virtual patch

This variable should be omitted if it will not be used in subsequent SmPL rules.


>    @@
>    expression buf, val;
>    @@
>    - snprintf(buf, PAGE_SIZE, "%d\n", val)
>    + spgprintf_d(buf, val)
>
> This works nearly always as expected, but not in some macros.

Do you get any more interesting test results for the following transformation approach?

@replacement@
@@
-snprintf
+spgprintf_d
 (...,
-PAGE_SIZE, "%d\n",
 ...)


Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Julia Lawall]

On Sun, 13 Oct 2019, Markus Elfring wrote:

> >    virtual patch
>
> This variable should be omitted if it will not be used in subsequent SmPL rules.

There is no harm to have it.

julia


>
>
> >    @@
> >    expression buf, val;
> >    @@
> >    - snprintf(buf, PAGE_SIZE, "%d\n", val)
> >    + spgprintf_d(buf, val)
> >
> > This works nearly always as expected, but not in some macros.
>
> Do you get any more interesting test results for the following transformation approach?
>
> @replacement@
> @@
> -snprintf
> +spgprintf_d
>  (...,
> -PAGE_SIZE, "%d\n",
>  ...)
>
>
> Regards,
> Markus
> _______________________________________________
> Cocci mailing list
> Cocci@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

> >   #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
> >
> > Is that on purpose? If yes, how can this be avoided?
>
> I don't think it should be on purpose.  Could you send some C code that
> illustrates the problem?

Does the semantic patch language (Coccinelle software) support
the adjustment of preprocessor definitions as in the shown
source code example?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of “virtual” SmPL variables

[Markus Elfring]

>>>    virtual patch
>>
>> This variable should be omitted if it will not be used in subsequent SmPL rules.
>
> There is no harm to have it.

Can you get additional software development concerns if you would look at
a bug report on a topic like “Metavariables with the type "virtual" prevent
proper initialisation for Python scripts.” once more?
https://github.com/coccinelle/coccinelle/issues/35

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of “virtual” SmPL variables

[Julia Lawall]

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



On Sun, 13 Oct 2019, Markus Elfring wrote:

> >>>    virtual patch
> >>
> >> This variable should be omitted if it will not be used in subsequent SmPL rules.
> >
> > There is no harm to have it.
>
> Can you get additional software development concerns if you would look at
> a bug report on a topic like “Metavariables with the type "virtual" prevent
> proper initialisation for Python scripts.” once more?
> https://github.com/coccinelle/coccinelle/issues/35

This comment is completely irrelevant.  There is a difference between a
virtual rule, that one can declare as being matched or not from the
command line, and a virtual metavariable in a script, that has to be bound
for the script to be executed.

julia

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting macros with SmPL?

[Markus Elfring]

>> Does the semantic patch language (Coccinelle software) support
>> the adjustment of preprocessor definitions as in the shown
>> source code example?
>
> Can't you find the answer to this question by yourself by trying it?

My test did not show an useful patch result for the shown SmPL transformation variant.


I probably know another answer already if no other news will be contributed.
Would you like to take another look at your commit from 2011-01-10?
https://github.com/coccinelle/coccinelle/commit/5e3f73c732075f7afadf383d088f3b6d0e1345b1

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting macros with SmPL?

[Julia Lawall]

On Sun, 13 Oct 2019, Markus Elfring wrote:

> >> Does the semantic patch language (Coccinelle software) support
> >> the adjustment of preprocessor definitions as in the shown
> >> source code example?
> >
> > Can't you find the answer to this question by yourself by trying it?
>
> My test did not show an useful patch result for the shown SmPL transformation variant.
>
>
> I probably know another answer already if no other news will be contributed.
> Would you like to take another look at your commit from 2011-01-10?
> https://github.com/coccinelle/coccinelle/commit/5e3f73c732075f7afadf383d088f3b6d0e1345b1

This seems completely irrelevant.  The question was about #define, not
about #ifdef.  Changes within #define code should be supported if
Coccinelle is able to parse the code independently of its usage context.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of “virtual” SmPL variables

[Markus Elfring]

>> https://github.com/coccinelle/coccinelle/issues/35
>
> This comment is completely irrelevant.

I have got an other view.


> There is a difference between a virtual rule, that one can declare
> as being matched or not from the command line, and a virtual metavariable
> in a script, that has to be bound for the script to be executed.

There are different uses to consider for this kind of SmPL variable,
aren't there?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting macros with SmPL?

[Markus Elfring]

>> https://github.com/coccinelle/coccinelle/commit/5e3f73c732075f7afadf383d088f3b6d0e1345b1
>
> This seems completely irrelevant.

I got an other view also for this software area.
How many items can be assumed behind the word “etc.” in the section “upcoming/planned/todo”?


> The question was about #define, not about #ifdef.

Can we clarify the corresponding details better then?


> Changes within #define code should be supported if Coccinelle is able to parse
> the code independently of its usage context.

Would you like to say that the desired software support is complete here?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting macros with SmPL?

[Markus Elfring]

> Changes within #define code should be supported if Coccinelle is able
> to parse the code independently of its usage context.

I suggest to take a closer look at the current software situation.

@replacement@
expression x;
identifier macro;
@@
 #define macro(name)
-snprintf
+spgprintf_d
 (...,
-PAGE_SIZE, "%d\n",
 (x)->name)


elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-cocci use_spgprintf2.cocci
…
minus: parse error:
  File "use_spgprintf2.cocci", line 11, column 0, charpos = 132
  around = '',
  whole content =


Can such an error message be explained better?


I imagine that context-dependent data processing will be needed here
to distinguish if preprocessor code should be adjusted (or not).
How much will this technical aspect matter?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting macros with SmPL?

[Julia Lawall]

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



On Mon, 14 Oct 2019, Markus Elfring wrote:

> > Changes within #define code should be supported if Coccinelle is able
> > to parse the code independently of its usage context.
>
> I suggest to take a closer look at the current software situation.
>
> @replacement@
> expression x;
> identifier macro;
> @@
>  #define macro(name)
> -snprintf
> +spgprintf_d
>  (...,
> -PAGE_SIZE, "%d\n",
>  (x)->name)
>
>
> elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-cocci use_spgprintf2.cocci
> …
> minus: parse error:
>   File "use_spgprintf2.cocci", line 11, column 0, charpos = 132
>   around = '',
>   whole content =
>
>
> Can such an error message be explained better?
>
>
> I imagine that context-dependent data processing will be needed here
> to distinguish if preprocessor code should be adjusted (or not).
> How much will this technical aspect matter?

Macros are supposed to be written on one line.

Anyway, to my understanding the goal was not to modify the #define part,
but rather only the code part.

julia

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting macros with SmPL?

[Markus Elfring]

>> I imagine that context-dependent data processing will be needed here
>> to distinguish if preprocessor code should be adjusted (or not).
>> How much will this technical aspect matter?
>
> Macros are supposed to be written on one line.

I suggest to reconsider also this view.
Would you like to take line continuations (or the escaping of line breaks)
into account?


> Anyway, to my understanding the goal was not to modify the #define part,
> but rather only the code part.

The shown transformation approach can probably be interpreted in two ways.

1. A source code modification should be performed behind a macro
   which can be empty.

2. Something should be generally adjusted. It would not matter then
   if the change is relevant (only) for preprocessor code (or not).


Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Julia Lawall]

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



On Mon, 14 Oct 2019, Jürgen Groß wrote:

> On 11.10.19 22:00, Julia Lawall wrote:
> >
> >
> > On Fri, 11 Oct 2019, Jürgen Groß wrote:
> >
> > > Hi,
> > >
> > > I have a simple semantic patch:
> > >
> > >    virtual patch
> > >
> > >    @@
> > >    expression buf, val;
> > >    @@
> > >    - snprintf(buf, PAGE_SIZE, "%d\n", val)
> > >    + spgprintf_d(buf, val)
> > >
> > > This works nearly always as expected, but not in some macros. The cases
> > > where it is not working are those when "val" is using a parameter of the
> > > macro, e.g.:
> > >
> > >    #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
> > >
> > > Is that on purpose? If yes, how can this be avoided?
> >
> > I don't think it should be on purpose.  Could you send some C code that
> > illustrates the problem?
>
> I have attached a little C file and a semantic patch, which I had
> located in a local directory.
>
> I invoke spatch via: "spatch --cocci-file patch.cocci --patch . --dir ."
>
> The result shows that the problem is a little bit different from my
> first analysis: whether a pattern is recognized or not seems to depend
> on macro parameter usage, which is not limited to the pattern itself.

Thanks for the examples.  The problem in these examples actually has
nothing to with parameter usage, but with the ability to parse the macro
definition.  I get:

 #define macro1a(par)            \
-        func(buf, 1, par)
+        func2(buf, par)

Tha above mentions a parameter but the code gets changed.  This case is no
problem because the body of the macro is an expression.


 #define macro1b(par)            \
         func(buf, 1, par)       \
         func(buf, 1, par)

Nothing happens here.  It is not possible in C to have one function call
after another like this.


 #define macro2a(par)            \
         par++;                  \
         func(buf, 1, 17)

Nothing happens here either.  Because the final ; is omitted the body of
the macro is not valid C.  But it doesn't work if you add a semicolon at
the end either.  It seems that a sequence of statements is not supported
either.  OOn the other hand, if you transform it into a do while(0), even
with no trailing semicolon after the while (0) all is fine.

 #define macro2b(par)            \
-        func(buf, 1, 17)
+        func2(buf, 17)

No problem again here.

julia

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

>  #define macro2a(par)            \
>          par++;                  \
>          func(buf, 1, 17)
>
> Nothing happens here either.

May I see also the complete source code examples?


> Because the final ; is omitted the body of the macro is not valid C.

I suggest to reconsider also this view.


> But it doesn't work if you add a semicolon at the end either.
> It seems that a sequence of statements is not supported either.

Do such software limitations become more interesting?


> On the other hand, if you transform it into a do while(0),
> even with no trailing semicolon after the while (0) all is fine.

Such a coding style can also help.
How will the affected software components be improved further?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Jürgen Groß]

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

On 14.10.19 13:14, Julia Lawall wrote:
> 
> 
> On Mon, 14 Oct 2019, Jürgen Groß wrote:
> 
>> On 11.10.19 22:00, Julia Lawall wrote:
>>>
>>>
>>> On Fri, 11 Oct 2019, Jürgen Groß wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a simple semantic patch:
>>>>
>>>>     virtual patch
>>>>
>>>>     @@
>>>>     expression buf, val;
>>>>     @@
>>>>     - snprintf(buf, PAGE_SIZE, "%d\n", val)
>>>>     + spgprintf_d(buf, val)
>>>>
>>>> This works nearly always as expected, but not in some macros. The cases
>>>> where it is not working are those when "val" is using a parameter of the
>>>> macro, e.g.:
>>>>
>>>>     #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
>>>>
>>>> Is that on purpose? If yes, how can this be avoided?
>>>
>>> I don't think it should be on purpose.  Could you send some C code that
>>> illustrates the problem?
>>
>> I have attached a little C file and a semantic patch, which I had
>> located in a local directory.
>>
>> I invoke spatch via: "spatch --cocci-file patch.cocci --patch . --dir ."
>>
>> The result shows that the problem is a little bit different from my
>> first analysis: whether a pattern is recognized or not seems to depend
>> on macro parameter usage, which is not limited to the pattern itself.
> 
> Thanks for the examples.  The problem in these examples actually has
> nothing to with parameter usage, but with the ability to parse the macro
> definition.  I get:
> 
>   #define macro1a(par)            \
> -        func(buf, 1, par)
> +        func2(buf, par)
> 
> Tha above mentions a parameter but the code gets changed.  This case is no
> problem because the body of the macro is an expression.
> 
> 
>   #define macro1b(par)            \
>           func(buf, 1, par)       \
>           func(buf, 1, par)
> 
> Nothing happens here.  It is not possible in C to have one function call
> after another like this.

Oh sorry, typo by me.

> 
> 
>   #define macro2a(par)            \
>           par++;                  \
>           func(buf, 1, 17)
> 
> Nothing happens here either.  Because the final ; is omitted the body of
> the macro is not valid C.  But it doesn't work if you add a semicolon at
> the end either.  It seems that a sequence of statements is not supported
> either.  OOn the other hand, if you transform it into a do while(0), even
> with no trailing semicolon after the while (0) all is fine.

This is not always possible. See the new example as attached.

This is more like the original problem (stripped down a lot).


Juergen

[-- Attachment #2: tst.c --]
[-- Type: text/x-csrc, Size: 881 bytes --]

#include <stdio.h>

#define macro1(prefix, name)                              \
static int func##prefix##_##name##_show(char *page)       \
{                                                         \
        return snprintf(page, 1, "%d\n", name);           \
}

#define macro2(name)                                      \
static int func##name##_show(char *page)                  \
{                                                         \
        int rb;                                           \
                                                          \
        rb = snprintf(page, 1, "%d\n", name);             \
                                                          \
        return rb;                                        \
}                                                         \
                                                          \
macro1(pre, name)

[-- Attachment #3: patch.cocci --]
[-- Type: text/plain, Size: 81 bytes --]

@@
expression buf, val;
@@
- snprintf(buf, 1, "%d\n", val)
+ spgprintf(buf, val)

[-- Attachment #4: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Julia Lawall]

> > the macro is not valid C.  But it doesn't work if you add a semicolon at
> > the end either.  It seems that a sequence of statements is not supported
> > either.  On the other hand, if you transform it into a do while(0), even
> > with no trailing semicolon after the while (0) all is fine.
>
> This is not always possible. See the new example as attached.
>
> This is more like the original problem (stripped down a lot).

At the moment, a complete function definition is not possible.  But I know
that this is a common case.  I'll see if it can be added without adding
parsing conflicts.  A sequence of statements did not work for this reason.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

> This works nearly always as expected, but not in some macros.

Do you find any information from previous bug reports
also helpful for the clarification of your use case?

Examples:
* Fix search for parameterised macros with SmPL
  https://github.com/coccinelle/coccinelle/issues/94

* Complete support for construction of #define directives
  https://github.com/coccinelle/coccinelle/issues/139

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

> There are no #defines in his semantic patch.

I noticed this implementation detail already from his clarification request.


> When will you notice that?

Can the shown transformation approaches be applied then also
to replacement lists (or would you prefer to refer to macro bodies)?

Example:
#define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)


Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

>> * Fix search for parameterised macros with SmPL
>>   https://github.com/coccinelle/coccinelle/issues/94
…
> There are no #defines in his semantic patch.

This design detail can probably be taken also better into account
if other software development challenges will finally be solved.

elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-c Jürgen_Groß-Beispiel1.c
…
(ONCE) LEXER:unrecognised symbol, in token rule:\
LEXER: WIERD end of file in string
PB: not found closing paren in fuzzy parsing
…
BAD:!!!!! #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
…



https://wiki.sei.cmu.edu/confluence/display/c/PRE11-C.+Do+not+conclude+macro+definitions+with+a+semicolon
https://gcc.gnu.org/onlinedocs/cpp/Swallowing-the-Semicolon.html

How will the software situation be improved further?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

> BAD:!!!!! #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)

I hope that a missing double quote character will not be overlooked again
for the specification of a format string.

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

>>> * Fix search for parameterised macros with SmPL
>>>   https://github.com/coccinelle/coccinelle/issues/94

There are further software development challenges to consider
around preprocessor code.

elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-c Jürgen_Groß-Beispiel2.c
…
ERROR-RECOV: found sync end of #define, line 1
…
parse error
 = File "Jürgen_Groß-Beispiel2.c", line 1, column 65, charpos = 65
  around = '(',
  whole content = #define MACRO(name) snprintf(buffer, PAGE_SIZE, "%u\n", pointer->(name));
badcount: 0
BAD:!!!!! #define MACRO(name) snprintf(buffer, PAGE_SIZE, "%u\n", pointer->(name));
…

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Julia Lawall]

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



On Tue, 15 Oct 2019, Markus Elfring wrote:

> >> * Fix search for parameterised macros with SmPL
> >>   https://github.com/coccinelle/coccinelle/issues/94
> …
> > There are no #defines in his semantic patch.
>
> This design detail can probably be taken also better into account
> if other software development challenges will finally be solved.
>
> elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-c Jürgen_Groß-Beispiel1.c
> …
> (ONCE) LEXER:unrecognised symbol, in token rule:\
> LEXER: WIERD end of file in string
> PB: not found closing paren in fuzzy parsing
> …
> BAD:!!!!! #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)

If a " is missing then the code can't be parsed and Coccinelle won't do
anything.  But I don't know if this was a bug in the original code or
something you have modified; you sent another message that did not have
this problem.

> https://wiki.sei.cmu.edu/confluence/display/c/PRE11-C.+Do+not+conclude+macro+definitions+with+a+semicolon
> https://gcc.gnu.org/onlinedocs/cpp/Swallowing-the-Semicolon.html
>
> How will the software situation be improved further?

What software situation?

julia

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting macros with SmPL?

[Markus Elfring]

> Macros are supposed to be written on one line.

I guess that you refer to a logical source line.
https://en.cppreference.com/w/c/language/translation_phases#Phase_2

I am looking for better support around changing contents from physical text lines
also by the means of the semantic patch language.


> Anyway, to my understanding the goal was not to modify the #define part,
> but rather only the code part.

The following transformation approach can produce an usable result
together with another small source file example.

@replacement@
expression buffer, x;
identifier macro;
@@
-#define macro(name) snprintf(buffer, PAGE_SIZE, "%u\n", (x)->name)
+#define macro(name) spgprintf_d(buffer, (x)->name)


Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

>> BAD:!!!!! #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
>
> If a " is missing then the code can't be parsed and Coccinelle won't do anything.

I would appreciate if the error reporting will become nicer.


> But I don't know if this was a bug in the original code

You should probably know also this detail from the initial clarification request.
https://systeme.lip6.fr/pipermail/cocci/2019-October/006413.html


> or something you have modified;

I copied a bit of questionable source code also for my test approaches.


> you sent another message that did not have this problem.

I needed also further moments to notice related glitches.


> What software situation?

There are various open issues to consider around safe transformations
also around preprocessor code (replacement lists), aren't there?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Markus Elfring]

>> BAD:!!!!! #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
>
> If a " is missing then the code can't be parsed and Coccinelle won't do anything.

I suggest to take additional software improvement opportunities into account.

Should a semantic patch language script become able to fix such questionable source code?

See also:
Add a metavariable for the handling of source code
https://github.com/coccinelle/coccinelle/issues/140


Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] macro parameters and expressions?

[Julia Lawall]

On Tue, 15 Oct 2019, Markus Elfring wrote:

> >> BAD:!!!!! #define MACRO(name)    snprintf(pg, PAGE_SIZE, %u\n", ptr->name)
> >
> > If a " is missing then the code can't be parsed and Coccinelle won't do anything.
>
> I suggest to take additional software improvement opportunities into account.
>
> Should a semantic patch language script become able to fix such questionable source code?

No.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjustments with SmPL after macros?

[Markus Elfring]

> Anyway, to my understanding the goal was not to modify the #define part,
> but rather only the code part.

Will it become supported by the semantic patch language to change
source code directly after the occurrence of an empty macro?

@replacement@
identifier M;
@@
 #define M
-snprintf
+spgprintf_d
 (...)


elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-cocci use_spgprintf5.cocci
…
minus: parse error:
  File "use_spgprintf5.cocci", line 8, column 0, charpos = 72
  around = '',
  whole content =


Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjustments with SmPL after macros?

[Julia Lawall]

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



On Wed, 16 Oct 2019, Markus Elfring wrote:

> > Anyway, to my understanding the goal was not to modify the #define part,
> > but rather only the code part.
>
> Will it become supported by the semantic patch language to change
> source code directly after the occurrence of an empty macro?
>
> @replacement@
> identifier M;
> @@
>  #define M
> -snprintf
> +spgprintf_d
>  (...)

I think you could put \ in your semantic patch, like in C, but I don't
know.

julia

>
>
> elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-cocci use_spgprintf5.cocci
> …
> minus: parse error:
>   File "use_spgprintf5.cocci", line 8, column 0, charpos = 72
>   around = '',
>   whole content =
>
>
> Regards,
> Markus
>

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjustments with SmPL after macros?

[Markus Elfring]

>> @replacement@
>> identifier M;
>> @@
>>  #define M
>> -snprintf
>> +spgprintf_d
>>  (...)
>
> I think you could put \ in your semantic patch, like in C,

I am interested also in the support for escaping of line breaks
according to the desired handling of logical source lines.
But how will the corresponding parsing become better for the shown
tiny SmPL test script?


> but I don't know.

How will the knowledge evolve further for affected areas?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjustments with SmPL after macros?

[Markus Elfring]

> You could try it?

I observed that both variants (and others) fail for this issue.
Can you reproduce the reported software difficulties also
in your current test system?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjustments with SmPL after macros?

[Markus Elfring]

>> @replacement@
>> identifier M;
>> @@
>>  #define M
>> -snprintf
>> +spgprintf_d
>>  (...)
>
> I think you could put \ in your semantic patch, like in C,

The escaping of line breaks would be required for the complete handling of
logical source lines.
Such functionality does not help with the shown test script for
the semantic patch language at the moment.


> but I don't know.

Can we change this aspect together?


>> elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-cocci use_spgprintf5.cocci
>> …
>> minus: parse error:
>>   File "use_spgprintf5.cocci", line 8, column 0, charpos = 72
>>   around = '',
>>   whole content =

Such an error message points some work in progress out.

* The data processing needs to be reconsidered for the safe support of
  object- and function-like macros.

* The explanation of the error reasons should become more helpful.


Thus I hope that more collateral evolution can happen for affected open issues.
I assume that software development efforts will evolve then in
an other way than a “quick fix”.

The current parsing approach is using the tools “ocamlyacc” and “Menhir”.
They support only the parsing technologies “LALR(1)” and “LR(1)”
(context-free grammars).

I imagine that context-dependent data processing will be needed.
I guess also that other development tools will be needed according to
the Chomsky–Schützenberger hierarchy.
https://en.wikipedia.org/wiki/Context-sensitive_grammar

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci