On 6/14/20 12:17 PM, Julia Lawall wrote:
>
>
> On Sun, 14 Jun 2020, Denis Efremov wrote:
>
>>
>>
>> On 6/5/20 11:51 PM, Julia Lawall wrote:
>>> Also, there is no need to exceed 80 characters here. You can put a
>>> newline in the middle of a \( ... \)
>>
>> It's required. Looks like it's
On Sun, 14 Jun 2020, Denis Efremov wrote:
>
>
> On 6/5/20 11:51 PM, Julia Lawall wrote:
> > Also, there is no need to exceed 80 characters here. You can put a
> > newline in the middle of a \( ... \)
>
> It's required. Looks like it's impossible to break "when" lines.
That's true. Sorry for
On 6/5/20 11:51 PM, Julia Lawall wrote:
> Also, there is no need to exceed 80 characters here. You can put a
> newline in the middle of a \( ... \)
It's required. Looks like it's impossible to break "when" lines.
... when != if (...) { ... E =
On Sat, 6 Jun 2020, Markus Elfring wrote:
> > +@choice@
> > +expression E, E1;
> > +position kok, vok;
> > +@@
> > +
> > +(
> > + if (...) {
> > +...
> > +E = \(kmalloc@kok\|…\)(...)
>
> Further implementation details from this SmPL script caught my software
> development attention.
>
> +@choice@
> +expression E, E1;
> +position kok, vok;
> +@@
> +
> +(
> + if (...) {
> +...
> +E = \(kmalloc@kok\|…\)(...)
Further implementation details from this SmPL script caught my software
development attention.
* Is there a need to add the specification “when any” to the SmPL
> > +E =
> > \(kmalloc@kok\|kzalloc@kok\|krealloc@kok\|kcalloc@kok\|kmalloc_node@kok\|kzalloc_node@kok\|kmalloc_array@kok\|kmalloc_array_node@kok\|kcalloc_node@kok\)(...)
>
> I would prefer an other coding style here.
>
> * Items for such SmPL disjunctions can be specified also on multiple
> Check that alloc and free types of functions match each other.
Further software development challenges are interesting also for such an use
case.
> +/// Check that kvmalloc'ed memory is freed by kfree functions,
> +/// vmalloc'ed by vfree functions and kvmalloc'ed by kvfree
> +/// functions.
On Sat, 6 Jun 2020, Denis Efremov wrote:
> On 6/5/20 11:51 PM, Julia Lawall wrote:
> > Is there a strong reason for putting the choice rule first? It may make
> > things somewhat slower than necessary, if it matches in many places,
> > because the opportunity rule will have to detect that it
On 6/5/20 11:51 PM, Julia Lawall wrote:
> Is there a strong reason for putting the choice rule first? It may make
> things somewhat slower than necessary, if it matches in many places,
> because the opportunity rule will have to detect that it doesn't care
> about all of those places.
No, I
On Fri, 5 Jun 2020, Denis Efremov wrote:
> Check that alloc and free types of functions match each other.
Is there a strong reason for putting the choice rule first? It may make
things somewhat slower than necessary, if it matches in many places,
because the opportunity rule will have to
Check that alloc and free types of functions match each other.
Signed-off-by: Denis Efremov
---
List of patches to stable:
- https://lkml.org/lkml/2020/6/1/713
- https://lkml.org/lkml/2020/6/5/200
- https://lkml.org/lkml/2020/6/5/838
- https://lkml.org/lkml/2020/6/5/887
Other patches:
-
11 matches
Mail list logo
