[Cocci] Weird whitespace behavior?

[Cocci] Weird whitespace behavior?

[Kees Cook]

Hi,

I've been doing some large treewide changes to the allocators, and I
notice that Coccinelle does something odd for a specific case. I have
two scripts, one operating on kmalloc() and one operating on
devm_kmalloc(). They are identical script except for the function
names, however, while kmalloc produces patches like this:

- foo = kmalloc(a * b, gfp);
+ foo = kmalloc_array(a, b, gfp);

the devm_kmalloc one produces:

- foo = devm_kmalloc(handle, a * b, gfp);
+ foo =devm_kmalloc_array(a, b, gfp);

I can't figure out why the space after "=" is missing and have been
manually fixing it up...

-Kees

-- 
Kees Cook
Pixel Security

[Cocci] Weird whitespace behavior?

[Kees Cook]

On Mon, Jun 11, 2018 at 4:17 PM, Kees Cook <keescook@google.com> wrote:
> Hi,
>
> I've been doing some large treewide changes to the allocators, and I
> notice that Coccinelle does something odd for a specific case. I have
> two scripts, one operating on kmalloc() and one operating on
> devm_kmalloc(). They are identical script except for the function
> names, however, while kmalloc produces patches like this:
>
> - foo = kmalloc(a * b, gfp);
> + foo = kmalloc_array(a, b, gfp);
>
> the devm_kmalloc one produces:
>
> - foo = devm_kmalloc(handle, a * b, gfp);
> + foo =devm_kmalloc_array(a, b, gfp);
>
> I can't figure out why the space after "=" is missing and have been
> manually fixing it up...

And while I'm at it... line breaks aren't working like I'd expect:

-               collection = kmalloc(sizeof(struct hid_collection) *
-                               parser->device->collection_size * 2,
GFP_KERNEL);
+               collection = kmalloc(array3_size(sizeof(struct
hid_collection), parser->device->collection_size, 2),
+                                    GFP_KERNEL);

Why wasn't array3_size() correctly line wrapped?

-Kees

-- 
Kees Cook
Pixel Security

[Cocci] Weird whitespace behavior?

[Julia Lawall]

On Mon, 11 Jun 2018, Kees Cook wrote:

> On Mon, Jun 11, 2018 at 4:17 PM, Kees Cook <keescook@google.com> wrote:
> > Hi,
> >
> > I've been doing some large treewide changes to the allocators, and I
> > notice that Coccinelle does something odd for a specific case. I have
> > two scripts, one operating on kmalloc() and one operating on
> > devm_kmalloc(). They are identical script except for the function
> > names, however, while kmalloc produces patches like this:
> >
> > - foo = kmalloc(a * b, gfp);
> > + foo = kmalloc_array(a, b, gfp);
> >
> > the devm_kmalloc one produces:
> >
> > - foo = devm_kmalloc(handle, a * b, gfp);
> > + foo =devm_kmalloc_array(a, b, gfp);
> >
> > I can't figure out why the space after "=" is missing and have been
> > manually fixing it up...

I would need your semantic patch to see the problem.

> And while I'm at it... line breaks aren't working like I'd expect:
>
> -               collection = kmalloc(sizeof(struct hid_collection) *
> -                               parser->device->collection_size * 2,
> GFP_KERNEL);
> +               collection = kmalloc(array3_size(sizeof(struct
> hid_collection), parser->device->collection_size, 2),
> +                                    GFP_KERNEL);
>
> Why wasn't array3_size() correctly line wrapped?

I think that line breaking only works on the outermost function call.

julia

[Cocci] Increasing usage of array allocation functions with SmPL

[SF Markus Elfring]

> I've been doing some large treewide changes to the allocators,

I find your update suggestion ?mm: Use overflow helpers in kmalloc_array*()? interesting.

https://lkml.org/lkml/2018/5/31/877
https://patchwork.kernel.org/patch/10442283/
https://lkml.kernel.org/r/<20180601004233.37822-7-keescook@chromium.org>


It seems that corresponding work became noteworthy news ?4.18 Merge window, part 2?.
https://lwn.net/Articles/757187/


Now I am curious on how software evolution will be continued according to such
a transformation pattern.
https://patchwork.kernel.org/project/LKML/list/?state=*&q=alloc_array


> and I notice that Coccinelle does something odd for a specific case.

Will there happen any more evolution in this software area?

Regards,
Markus