[cocci] Returning statically allocated nested structs

[cocci] Returning statically allocated nested structs

[Peter Senna Tschudin]

Dear list,

I am trying to come up with a semantic patch to detect uses of nested
structs, more specifically:
 - the nested struct is statically allocated
 - the statically allocated nested struct is returned by a function.

Here is an example:

struct inner {

    /* some inner struct stuff*/

} inner;

struct outer  {

    /* some outer struct stuff*/

    struct inner i; // The kind of nesting I care about
    struct inner is[SOME_MAGIC_NUMBER]; // The kind of nesting I care about too

    struct inner *ip; // Nah, this is boring. I don't care about boring
} outer;

void sillyfu() {
    struct outer ou = { }; // initialization does not matter.
    struct outer *oup = NULL; // Nah, this is boring. I don't care about boring

    /* some serious silly stuff */

    return ou;
}

I remember that there are some details for detecting structs
effectively, and as I am investigating a code base with over 1.2M
lines of code, I would like to ask for pointers of where to start.

Thank you!

Peter

-- 
                         Peter

Re: [cocci] Returning statically allocated nested structs

[Julia Lawall]

On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:

> Dear list,
>
> I am trying to come up with a semantic patch to detect uses of nested
> structs, more specifically:
>  - the nested struct is statically allocated
>  - the statically allocated nested struct is returned by a function.
>
> Here is an example:
>
> struct inner {
>
>     /* some inner struct stuff*/
>
> } inner;
>
> struct outer  {
>
>     /* some outer struct stuff*/
>
>     struct inner i; // The kind of nesting I care about
>     struct inner is[SOME_MAGIC_NUMBER]; // The kind of nesting I care about too
>
>     struct inner *ip; // Nah, this is boring. I don't care about boring
> } outer;
>
> void sillyfu() {
>     struct outer ou = { }; // initialization does not matter.
>     struct outer *oup = NULL; // Nah, this is boring. I don't care about boring
>
>     /* some serious silly stuff */
>
>     return ou;

Not sure to understand.  The return type of the function is void.  Was
that a typo?

Returning a structure in general seems like something to be concerned
about.  Does it matter that another structure is nested inside?

julia

> }
>
> I remember that there are some details for detecting structs
> effectively, and as I am investigating a code base with over 1.2M
> lines of code, I would like to ask for pointers of where to start.
>
> Thank you!
>
> Peter
>
> --
>                          Peter
>

Re: [cocci] Returning statically allocated nested structs

[Peter Senna Tschudin]

Hi Julia,

Thanks for the reply!

On Thu, Mar 28, 2024 at 10:08 AM Julia Lawall <julia.lawall@inria.fr> wrote:
>
>
>
> On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:
>
> > Dear list,
> >
> > I am trying to come up with a semantic patch to detect uses of nested
> > structs, more specifically:
> >  - the nested struct is statically allocated
> >  - the statically allocated nested struct is returned by a function.
> >
> > Here is an example:
> >
> > struct inner {
> >
> >     /* some inner struct stuff*/
> >
> > } inner;
> >
> > struct outer  {
> >
> >     /* some outer struct stuff*/
> >
> >     struct inner i; // The kind of nesting I care about
> >     struct inner is[SOME_MAGIC_NUMBER]; // The kind of nesting I care about too
> >
> >     struct inner *ip; // Nah, this is boring. I don't care about boring
> > } outer;
> >
> > void sillyfu() {
Argh, that was a typo!

struct outer sillyfu() {
> >     struct outer ou = { }; // initialization does not matter.
> >     struct outer *oup = NULL; // Nah, this is boring. I don't care about boring
> >
> >     /* some serious silly stuff */
> >
> >     return ou;
>
> Not sure to understand.  The return type of the function is void.  Was
> that a typo?
>
> Returning a structure in general seems like something to be concerned
> about.  Does it matter that another structure is nested inside?

I am not sure if it matters, but it may. The compiler seems to be the
arbiter who decides what happens when returning a local struct. It may
work, it may not. One theory for not working is variable scope.
Returning a local struct may not work due to the local nature of the
struct. In this case the compiler would free the memory used by the
struct when the function returns, causing undefined behavior. In this
scenario the nested struct simply adds another layer of the same
problem.

Another theory says that the compiler may decide based on the struct
size. The compiler may tolerate returning certain struct sizes, but
not others.





>
> julia
>
> > }
> >
> > I remember that there are some details for detecting structs
> > effectively, and as I am investigating a code base with over 1.2M
> > lines of code, I would like to ask for pointers of where to start.
> >
> > Thank you!
> >
> > Peter
> >
> > --
> >                          Peter
> >



-- 
                         Peter

Re: [cocci] Returning statically allocated nested structs

[Julia Lawall]

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



On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:

> Hi Julia,
>
> Thanks for the reply!
>
> On Thu, Mar 28, 2024 at 10:08 AM Julia Lawall <julia.lawall@inria.fr> wrote:
> >
> >
> >
> > On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:
> >
> > > Dear list,
> > >
> > > I am trying to come up with a semantic patch to detect uses of nested
> > > structs, more specifically:
> > >  - the nested struct is statically allocated
> > >  - the statically allocated nested struct is returned by a function.
> > >
> > > Here is an example:
> > >
> > > struct inner {
> > >
> > >     /* some inner struct stuff*/
> > >
> > > } inner;
> > >
> > > struct outer  {
> > >
> > >     /* some outer struct stuff*/
> > >
> > >     struct inner i; // The kind of nesting I care about
> > >     struct inner is[SOME_MAGIC_NUMBER]; // The kind of nesting I care about too
> > >
> > >     struct inner *ip; // Nah, this is boring. I don't care about boring
> > > } outer;
> > >
> > > void sillyfu() {
> Argh, that was a typo!
>
> struct outer sillyfu() {
> > >     struct outer ou = { }; // initialization does not matter.
> > >     struct outer *oup = NULL; // Nah, this is boring. I don't care about boring
> > >
> > >     /* some serious silly stuff */
> > >
> > >     return ou;
> >
> > Not sure to understand.  The return type of the function is void.  Was
> > that a typo?
> >
> > Returning a structure in general seems like something to be concerned
> > about.  Does it matter that another structure is nested inside?
>
> I am not sure if it matters, but it may. The compiler seems to be the
> arbiter who decides what happens when returning a local struct. It may
> work, it may not. One theory for not working is variable scope.
> Returning a local struct may not work due to the local nature of the
> struct. In this case the compiler would free the memory used by the
> struct when the function returns, causing undefined behavior. In this
> scenario the nested struct simply adds another layer of the same
> problem.
>
> Another theory says that the compiler may decide based on the struct
> size. The compiler may tolerate returning certain struct sizes, but
> not others.

The following is not tested, but seems like it should be sufficient.

@r@
identifier i, j, k;
@@

struct i { ...
  struct j k;
  ...
};

@@
identifier r.i;
identifier f,x;
@@

f(...) {
  struct i x = ...;
  ...
* return x;
}

julia

Re: [cocci] Returning statically allocated nested structs

[Peter Senna Tschudin]

Thanks Julia,

Your question about nesting inspired me to a simpler solution:

@rule1@
identifier i, s;
position p;
@@
struct i s;
...
return@p s;

@script:python@
p << rule1.p;
s << rule1.s;
@@
cocci.print_main(s, p)

Do I need to worry about calling cocci.print_secs() after the print_main()?

On Thu, Mar 28, 2024 at 11:10 AM Julia Lawall <julia.lawall@inria.fr> wrote:
>
>
>
> On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:
>
> > Hi Julia,
> >
> > Thanks for the reply!
> >
> > On Thu, Mar 28, 2024 at 10:08 AM Julia Lawall <julia.lawall@inria.fr> wrote:
> > >
> > >
> > >
> > > On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:
> > >
> > > > Dear list,
> > > >
> > > > I am trying to come up with a semantic patch to detect uses of nested
> > > > structs, more specifically:
> > > >  - the nested struct is statically allocated
> > > >  - the statically allocated nested struct is returned by a function.
> > > >
> > > > Here is an example:
> > > >
> > > > struct inner {
> > > >
> > > >     /* some inner struct stuff*/
> > > >
> > > > } inner;
> > > >
> > > > struct outer  {
> > > >
> > > >     /* some outer struct stuff*/
> > > >
> > > >     struct inner i; // The kind of nesting I care about
> > > >     struct inner is[SOME_MAGIC_NUMBER]; // The kind of nesting I care about too
> > > >
> > > >     struct inner *ip; // Nah, this is boring. I don't care about boring
> > > > } outer;
> > > >
> > > > void sillyfu() {
> > Argh, that was a typo!
> >
> > struct outer sillyfu() {
> > > >     struct outer ou = { }; // initialization does not matter.
> > > >     struct outer *oup = NULL; // Nah, this is boring. I don't care about boring
> > > >
> > > >     /* some serious silly stuff */
> > > >
> > > >     return ou;
> > >
> > > Not sure to understand.  The return type of the function is void.  Was
> > > that a typo?
> > >
> > > Returning a structure in general seems like something to be concerned
> > > about.  Does it matter that another structure is nested inside?
> >
> > I am not sure if it matters, but it may. The compiler seems to be the
> > arbiter who decides what happens when returning a local struct. It may
> > work, it may not. One theory for not working is variable scope.
> > Returning a local struct may not work due to the local nature of the
> > struct. In this case the compiler would free the memory used by the
> > struct when the function returns, causing undefined behavior. In this
> > scenario the nested struct simply adds another layer of the same
> > problem.
> >
> > Another theory says that the compiler may decide based on the struct
> > size. The compiler may tolerate returning certain struct sizes, but
> > not others.
>
> The following is not tested, but seems like it should be sufficient.
>
> @r@
> identifier i, j, k;
> @@
>
> struct i { ...
>   struct j k;
>   ...
> };
>
> @@
> identifier r.i;
> identifier f,x;
> @@
>
> f(...) {
>   struct i x = ...;
>   ...
> * return x;
> }
>
> julia



-- 
                         Peter

Re: [cocci] Returning statically allocated nested structs

[Julia Lawall]

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



On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:

> Thanks Julia,
>
> Your question about nesting inspired me to a simpler solution:
>
> @rule1@

You could add the word exists after rule1, in case some other returns do
something different.

> identifier i, s;
> position p;
> @@
> struct i s;
> ...
> return@p s;
>
> @script:python@
> p << rule1.p;
> s << rule1.s;
> @@
> cocci.print_main(s, p)
>
> Do I need to worry about calling cocci.print_secs() after the print_main()?

No, just print_main is fine.

julia

>
> On Thu, Mar 28, 2024 at 11:10 AM Julia Lawall <julia.lawall@inria.fr> wrote:
> >
> >
> >
> > On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:
> >
> > > Hi Julia,
> > >
> > > Thanks for the reply!
> > >
> > > On Thu, Mar 28, 2024 at 10:08 AM Julia Lawall <julia.lawall@inria.fr> wrote:
> > > >
> > > >
> > > >
> > > > On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:
> > > >
> > > > > Dear list,
> > > > >
> > > > > I am trying to come up with a semantic patch to detect uses of nested
> > > > > structs, more specifically:
> > > > >  - the nested struct is statically allocated
> > > > >  - the statically allocated nested struct is returned by a function.
> > > > >
> > > > > Here is an example:
> > > > >
> > > > > struct inner {
> > > > >
> > > > >     /* some inner struct stuff*/
> > > > >
> > > > > } inner;
> > > > >
> > > > > struct outer  {
> > > > >
> > > > >     /* some outer struct stuff*/
> > > > >
> > > > >     struct inner i; // The kind of nesting I care about
> > > > >     struct inner is[SOME_MAGIC_NUMBER]; // The kind of nesting I care about too
> > > > >
> > > > >     struct inner *ip; // Nah, this is boring. I don't care about boring
> > > > > } outer;
> > > > >
> > > > > void sillyfu() {
> > > Argh, that was a typo!
> > >
> > > struct outer sillyfu() {
> > > > >     struct outer ou = { }; // initialization does not matter.
> > > > >     struct outer *oup = NULL; // Nah, this is boring. I don't care about boring
> > > > >
> > > > >     /* some serious silly stuff */
> > > > >
> > > > >     return ou;
> > > >
> > > > Not sure to understand.  The return type of the function is void.  Was
> > > > that a typo?
> > > >
> > > > Returning a structure in general seems like something to be concerned
> > > > about.  Does it matter that another structure is nested inside?
> > >
> > > I am not sure if it matters, but it may. The compiler seems to be the
> > > arbiter who decides what happens when returning a local struct. It may
> > > work, it may not. One theory for not working is variable scope.
> > > Returning a local struct may not work due to the local nature of the
> > > struct. In this case the compiler would free the memory used by the
> > > struct when the function returns, causing undefined behavior. In this
> > > scenario the nested struct simply adds another layer of the same
> > > problem.
> > >
> > > Another theory says that the compiler may decide based on the struct
> > > size. The compiler may tolerate returning certain struct sizes, but
> > > not others.
> >
> > The following is not tested, but seems like it should be sufficient.
> >
> > @r@
> > identifier i, j, k;
> > @@
> >
> > struct i { ...
> >   struct j k;
> >   ...
> > };
> >
> > @@
> > identifier r.i;
> > identifier f,x;
> > @@
> >
> > f(...) {
> >   struct i x = ...;
> >   ...
> > * return x;
> > }
> >
> > julia
>
>
>
> --
>                          Peter
>

Re: [cocci] Returning statically allocated nested structs

[Peter Senna Tschudin]

On Thu, Mar 28, 2024 at 3:49 PM Julia Lawall <julia.lawall@inria.fr> wrote:
>
>
>
> On Thu, 28 Mar 2024, Peter Senna Tschudin wrote:
>
> > Thanks Julia,
> >
> > Your question about nesting inspired me to a simpler solution:
> >
> > @rule1@
>
> You could add the word exists after rule1, in case some other returns do
> something different.

Oh thanks, Coccinelle found 36 instead of 35 occurrences after adding exists.

Thanks!

[...]


-- 
                         Peter