[Cocci] adding function declarations

[Cocci] adding function declarations

[Christof Warlich]

Hi,

being absolutely new to Coccinelle, I see that fascinating things can be 
done with it, but I kind of fail to adopt things towards my own needs:

I'd like to adapt the header files of a huge C project (gcc) so that 
they may alternatively be included by C++ (g++) code. But many of the 
header files do contain numerous inline function definitions of the form

static inline __attribute__((always_inline)) <someReturnType> 
<someFunctionName>(<someParameters) {
     <someCode>
}

While gcc happily accepts this type of code, g++ complains that 
specifying attributes is not allowed during function definition, but 
only during function declaration. Thus, the fix is straight forward: All 
these occurrences must be replaced by something like

static inline __attribute__((always_inline)) <someReturnType> 
<someFunctionName>(<someParameters);
<someReturnType> <someFunctionName>(<someParameters) {
     <someCode>
}

Can anyone give me some guidance on how I can express this as a semantic 
patch?

Thanks for any help,

Chris

[Cocci] adding function declarations

[Julia Lawall]

On Thu, 1 Jan 2015, Christof Warlich wrote:

> Hi,
> 
> being absolutely new to Coccinelle, I see that fascinating things can be done
> with it, but I kind of fail to adopt things towards my own needs:
> 
> I'd like to adapt the header files of a huge C project (gcc) so that they may
> alternatively be included by C++ (g++) code. But many of the header files do
> contain numerous inline function definitions of the form
> 
> static inline __attribute__((always_inline)) <someReturnType>
> <someFunctionName>(<someParameters) {
>     <someCode>
> }
> 
> While gcc happily accepts this type of code, g++ complains that specifying
> attributes is not allowed during function definition, but only during
> function declaration. Thus, the fix is straight forward: All these
> occurrences must be replaced by something like
> 
> static inline __attribute__((always_inline)) <someReturnType>
> <someFunctionName>(<someParameters);
> <someReturnType> <someFunctionName>(<someParameters) {
>     <someCode>
> }
> 
> Can anyone give me some guidance on how I can express this as a semantic
> patch?

Unfortunately, there is no way to match against attributes.  But it should 
be possible to add them.  Is the attribute in question always 
__attribute__((always_inline))?  Could it occur that some static inline 
functions don't have this attribute?  In that case would it be OK to add 
the atribute anyway?  Is it necessary to check for an existing function 
declaration, or can one assume that it never exists?

julia

[Cocci] adding function declarations

[Christof Warlich]

Wow - that's been a really fast response :-)

Well, the "huge C project" I talked about is the linux kernel, or more 
precisely, its header files:
Having a few days off, I was curious to see how much effort it may take 
to allow writing modules in C++.

With respect to the static inline functions, it looks like there are no 
already existing function declaration that needs to be checked for, and 
the functions
are actually simply defined along the lines

static inline <someReturnType> <someFunctionName>(<someParameters) { 
<someCode> }

but "inline" is a macro which is defined as

#define inline inline __attribute__((always_inline)) notrace

or

#define inline inline notrace

depending on the kernel configuration, with notrace defined as

#define notrace __attribute__((no_instrument_function))

Thus, it should be possible to let Coccinelle see only the inline 
keyword, without the additional hassle that may be introduced by attributes.

I have some appointment right now, but I'll definitely come back 
tomorrow morning. Thanks a lot for looking into this so far!

Cheers,

Chris

Am 01.01.2015 um 17:02 schrieb Julia Lawall:
> On Thu, 1 Jan 2015, Christof Warlich wrote:
>
>> Hi,
>>
>> being absolutely new to Coccinelle, I see that fascinating things can be done
>> with it, but I kind of fail to adopt things towards my own needs:
>>
>> I'd like to adapt the header files of a huge C project (gcc) so that they may
>> alternatively be included by C++ (g++) code. But many of the header files do
>> contain numerous inline function definitions of the form
>>
>> static inline __attribute__((always_inline)) <someReturnType>
>> <someFunctionName>(<someParameters) {
>>      <someCode>
>> }
>>
>> While gcc happily accepts this type of code, g++ complains that specifying
>> attributes is not allowed during function definition, but only during
>> function declaration. Thus, the fix is straight forward: All these
>> occurrences must be replaced by something like
>>
>> static inline __attribute__((always_inline)) <someReturnType>
>> <someFunctionName>(<someParameters);
>> <someReturnType> <someFunctionName>(<someParameters) {
>>      <someCode>
>> }
>>
>> Can anyone give me some guidance on how I can express this as a semantic
>> patch?
> Unfortunately, there is no way to match against attributes.  But it should
> be possible to add them.  Is the attribute in question always
> __attribute__((always_inline))?  Could it occur that some static inline
> functions don't have this attribute?  In that case would it be OK to add
> the atribute anyway?  Is it necessary to check for an existing function
> declaration, or can one assume that it never exists?
>
> julia

[Cocci] adding function declarations

[Julia Lawall]

On Thu, 1 Jan 2015, Christof Warlich wrote:

> Wow - that's been a really fast response :-)
> 
> Well, the "huge C project" I talked about is the linux kernel, or more
> precisely, its header files:
> Having a few days off, I was curious to see how much effort it may take to
> allow writing modules in C++.
> 
> With respect to the static inline functions, it looks like there are no
> already existing function declaration that needs to be checked for, and the
> functions
> are actually simply defined along the lines
> 
> static inline <someReturnType> <someFunctionName>(<someParameters) {
> <someCode> }
> 
> but "inline" is a macro which is defined as
> 
> #define inline inline __attribute__((always_inline)) notrace
> 
> or
> 
> #define inline inline notrace
> 
> depending on the kernel configuration, with notrace defined as
> 
> #define notrace __attribute__((no_instrument_function))
> 
> Thus, it should be possible to let Coccinelle see only the inline keyword,
> without the additional hassle that may be introduced by attributes.
> 
> I have some appointment right now, but I'll definitely come back tomorrow
> morning. Thanks a lot for looking into this so far!

Now I'm not sure what is wanted to be done.  It seems like you would want 
to choose the configuration options that give you

#define inline inline notrace

because even if Coccinelle makes a prototype with the right arribute 
declaration, the other macro definition is still going to expand to 
something that the compiler doesn't like.  If there is a way to get 
notrace to expand to nothing, then it seems like everything would be OK?

julia

[Cocci] adding function declarations

[Christof Warlich]

 > Now I'm not sure what is wanted to be done.

Sorry if my last mail caused confusion: I just thought I may simplify 
things by suggesting to avoid expanding the "inline" macro for 
generating the semantic patch at all: Without "inline" being defined as 
a macro, Coccinelle would no see any attributes at all, so that the 
complete task of the semantic patch boils down to converting

static inline <someType> <someFunctionName>(<someParameterList>) {
     <someCode>
}

to

static inline <someType> <someFunctionName>(<someParameterList>);
<someType> <someFunctionName>(<someParameterList>) {
     <someCode>
}

Then, after creating and applying the semantic patch that does the 
conversion described above, the linux build process would do its macro 
magic as usual, causing the preprocessor to do its work, e.g. replacing 
"inline" by "inline __attribute__((always_inline)) 
__attribute__((no_instrument_function))". Doing so would make g++ happy 
as well, as the attributes are now only present in the function's 
declaration instead of the functions definition.

[Cocci] adding function declarations

[Julia Lawall]

On Fri, 2 Jan 2015, Christof Warlich wrote:

> > Now I'm not sure what is wanted to be done.
> 
> Sorry if my last mail caused confusion: I just thought I may simplify things
> by suggesting to avoid expanding the "inline" macro for generating the
> semantic patch at all: Without "inline" being defined as a macro, Coccinelle
> would no see any attributes at all, so that the complete task of the semantic
> patch boils down to converting
> 
> static inline <someType> <someFunctionName>(<someParameterList>) {
>     <someCode>
> }
> 
> to
> 
> static inline <someType> <someFunctionName>(<someParameterList>);
> <someType> <someFunctionName>(<someParameterList>) {
>     <someCode>
> }
> 
> Then, after creating and applying the semantic patch that does the conversion
> described above, the linux build process would do its macro magic as usual,
> causing the preprocessor to do its work, e.g. replacing "inline" by "inline
> __attribute__((always_inline)) __attribute__((no_instrument_function))". Doing
> so would make g++ happy as well, as the attributes are now only present in the
> function's declaration instead of the functions definition.

Shouldn't the static also be in the definition?

julia

[Cocci] adding function declarations

[Christof Warlich]

 > Shouldn't the static also be in the definition? julia

As much as g++ is concerned, the static may or may not be part of the 
definition: At least the following

$ cat xxx.cc
static inline int f();
int f(void) {
     return 0;
}

compiles fine with

$ g++ -c -Wall -Wextra -Weffc++ -Wpedantic xxx.cc

[Cocci] adding function declarations

[Julia Lawall]

Unfortunately, your seemingly simple request raises some issues :)

First, you should apply the patch below to Coccinelle version 1.0.0-rc23 
(the latest version).

Second here is a semantic patch that goes in the right direction, but is 
not perfect:

@@
type T;
identifier f;
parameter list ps;
@@

+static __attribute__((always_inline)) T f(ps);
-static inline T
+static inline T
f(ps) { ... }

For some reason, the semantic patch parser is not allowing me to put 
inline in the prototype.  I will look into it and send another patch.

Also for the following file:

static inline __attribute__((always_inline)) int foo(int x) {
  return x;
}

the output is missing a space before the attribute:

diff = 
--- tests/statinl.c
+++ /tmp/cocci-output-32260-27b877-statinl.c
@@ -1,3 +1,4 @@
-static inline __attribute__((always_inline)) int foo(int x) {
+static__attribute__((always_inline)) int foo(int x);
+static inline int foo(int x) {
   return x;
 }

I will look into this as well.

julia

[Cocci] adding function declarations

[Christof Warlich]

Am 01.01.2015 um 18:33 schrieb Julia Lawall:

 > Unfortunately, your seemingly simple request raises some issues :)

 > First, you should apply the patch below to Coccinelle version 
1.0.0-rc23 (the latest version)

It looks like you missed to include the patch you mentioned: I couldn't 
find anything appropriate to apply to the Coccinelle source code. Thus, 
I'm still playing with an unpatched version 1.0.0-rc23.

 > For some reason, the semantic patch parser is not allowing me to put
 > inline in the prototype. I will look into it and send another patch.
 >
 > Also for the following file:
 >
 > static inline __attribute__((always_inline)) int foo(int x) {
 >     return x;
 > }
 >
 > the output is missing a space before the attribute:
 > ...

Yes, I could reproduce both using 1.0.0-rc23.

 > I will look into this as well.

Again, many thanks for your help and your precious  time: So I'll 
patiently wait for a patch :-). But please let me know if anything else 
can be done on my side.

Cheers,

Chris

[Cocci] adding function declarations

[Julia Lawall]

On Fri, 2 Jan 2015, Christof Warlich wrote:

> Am 01.01.2015 um 18:33 schrieb Julia Lawall:
>
> > Unfortunately, your seemingly simple request raises some issues :)
>
> > First, you should apply the patch below to Coccinelle version 1.0.0-rc23
> (the latest version)
>
> It looks like you missed to include the patch you mentioned: I couldn't find
> anything appropriate to apply to the Coccinelle source code. Thus, I'm still
> playing with an unpatched version 1.0.0-rc23.
>
> > For some reason, the semantic patch parser is not allowing me to put
> > inline in the prototype. I will look into it and send another patch.
> >
> > Also for the following file:
> >
> > static inline __attribute__((always_inline)) int foo(int x) {
> >     return x;
> > }
> >
> > the output is missing a space before the attribute:
> > ...
>
> Yes, I could reproduce both using 1.0.0-rc23.

Interesting.  For me, without the patch, it crashed.

julia

[Cocci] adding function declarations

[Christof Warlich]

 > Interesting. For me, without the patch, it crashed.

That's strange indeed. I'm running Kubuntu 14.04 on x86_64:

$ uname -a
Linux shrek 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux

and I don't see a crash with neither the precompiled Coccinelle Ubuntu 
PPA nor with building it from the current (1.0.0-rc23) source.

Anyhow, I've applied the patch now, even if it may only be to have the 
proper base for subsequent patches.

Cheers,

Chris