Re: [Cocci] might be bug report, breaking up of a comment

On Sat, 17 Feb 2018, Robert Larice wrote: > Julia Lawall writes: > > > On Sat, 17 Feb 2018, Robert Larice wrote: > > > >> Hello, > >> > >> attached is a small example which seems to > >> break up a comment line, > >> thus commenting out following lines. > >> >

Re: [Cocci] might be bug report, breaking up of a comment

Julia Lawall writes: > On Sat, 17 Feb 2018, Robert Larice wrote: > >> Hello, >> >> attached is a small example which seems to >> break up a comment line, >> thus commenting out following lines. >> >> Please look at the "long reuse" line >> which will have an

Re: [Cocci] might be bug report, breaking up of a comment

On Sat, 17 Feb 2018, Robert Larice wrote: > Hello, > > attached is a small example which seems to > break up a comment line, > thus commenting out following lines. > > Please look at the "long reuse" line > which will have an open comment when spatch is run, > thus

[Cocci] might be bug report, breaking up of a comment

Hello, attached is a small example which seems to break up a comment line, thus commenting out following lines. Please look at the "long reuse" line which will have an open comment when spatch is run, thus commenting out the following "struct line *options" Best Regards,

Re: [Cocci] Checking for questionable error messages after failed memory allocations

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > Which confidence categorisation would fit here? > >>> > >>> Low. > >> > >> May scripts with this view be integrated? > > > > It's possible. > > Will the integration make more sense when the duplication of > regular expressions for SmPL

Re: [Cocci] Checking for questionable error messages after failed memory allocations

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >> Which confidence categorisation would fit here? > > > > Low. > > May scripts with this view be integrated? It's possible. It depends on the benefit of the transformation provided. > > The script has no idea whether the printed string is

Re: [Cocci] Determination for the absence of an option in a function call

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >>> f(...,<+...__GFP_NOWARN...+>,...) > >> > >> Does this SmPL specification mean that the identifier can appear anywhere > >> within the function call parameters? > > > > Yes. > > > >> Would it be acceptable for a risk level of false positives to

Re: [Cocci] Determination for the absence of an option in a function call

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > > f(...,<+...__GFP_NOWARN...+>,...) > > Does this SmPL specification mean that the identifier can appear anywhere > within the function call parameters? Yes. > Would it be acceptable for a risk level of false positives to omit > the check for

Re: [Cocci] Handling of variations in function call parameters

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >> I guess that it covers only a part of the desired search automation. > >> The generic handling of variations in parameter positions is > >> more challenging, isn't it? > > > > With iteration you can collect some information on one pass and use

Re: [Cocci] Determination for the absence of an option in a function call

> I guess that it covers only a part of the desired search automation. > The generic handling of variations in parameter positions is > more challenging, isn't it? With iteration you can collect some information on one pass and use it on another pass. This is discussed in the following set of

Re: [Cocci] Determination for the absence of an option in a function call

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >> It is easy to check the presence of such an identifier. > >> But I find it very challenging to determine (by script code) > >> if it is actually not passed (as an option) in a function call. > > > > It's not clear what you want. > > Another try

Re: [Cocci] Determination for the absence of an option in a function call

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >> I am working with the determination for memory allocation functions > >> from Linux source files for a while. > >> It matters in this software domain if the option “__GFP_NOWARN” was applied > >> (or not). > > > > <+...__GFP_NOWARN...+> in the

Re: [Cocci] Determination for the absence of an option in a function call

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >> But a safer source code analysis requires to distinguish these parameters > >> in > >> more detail. > >> > >> 1. How should be ensured that a specific option was not passed? > >> > >> 2. The parameter number becomes also relevant then. > >>

Re: [Cocci] Determination for the absence of an option in a function call

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > Hello, > > I am working with the following specification in some scripts for the semantic > patch language. > > … > target = action(...); > … > > > This source code search pattern shows that a return value from a function call > should be stored

[Cocci] Determination for the absence of an option in a function call

Hello, I am working with the following specification in some scripts for the semantic patch language. … target = action(...); … This source code search pattern shows that a return value from a function call should be stored somewhere. The concrete call is restricted by a selection of function

Re: [Cocci] Clarification for scripted SmPL constraints

>> Which parameters should be passed to the selected function? > > You can always pass the declared metavariable. I have got special imaginations for convenient parameter passing in such an use case. > You can put a comma-separated list of inherited metavariables Do you suggest that a

Re: [Cocci] please help me with a failing match

Julia Lawall writes: > On Sat, 17 Feb 2018, Robert Larice wrote: > >> Julia Lawall writes: >> >> > On Sat, 10 Feb 2018, Robert Larice wrote: >> > >> >> Julia Lawall writes: >> >> >> >> > On Sat, 10 Feb 2018, Robert Larice wrote:

Re: [Cocci] Clarification for scripted SmPL constraints

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >> I would appreciate if the place for the desired predicate will be better > >> explained. > >> > >> May they refer to a predefined function? > > > > When you write eg > > > > identifier x : script:python(...) { ... }; > > > > or > > > >

Re: [Cocci] Avoiding code duplication for SmPL constraints

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > >> Now I am looking again for further possibilities to avoid corresponding > >> code duplication. > >> > >> * Scripted constraints might be a design option. > >> Unfortunately, I find the documentation for this functionality still > >>

Re: [Cocci] Avoiding code duplication for SmPL constraints

On Sat, 17 Feb 2018, SF Markus Elfring wrote: > Hello, > > Constraints can be specified for metavariables of the semantic patch language. > I noticed that they can trigger software maintenance challenges > when bigger specifications are repeated in some SmPL rules. > Now I am looking again for

[Cocci] Avoiding code duplication for SmPL constraints

Hello, Constraints can be specified for metavariables of the semantic patch language. I noticed that they can trigger software maintenance challenges when bigger specifications are repeated in some SmPL rules. Now I am looking again for further possibilities to avoid corresponding code

Re: [Cocci] please help me with a failing match

On Sat, 17 Feb 2018, Robert Larice wrote: > Julia Lawall writes: > > > On Sat, 10 Feb 2018, Robert Larice wrote: > > > >> Julia Lawall writes: > >> > >> > On Sat, 10 Feb 2018, Robert Larice wrote: > >> > > >> >> Dear People, > >> >> > >> >> I'm

Re: [Cocci] please help me with a failing match

Julia Lawall writes: > On Sat, 10 Feb 2018, Robert Larice wrote: > >> Julia Lawall writes: >> >> > On Sat, 10 Feb 2018, Robert Larice wrote: >> > >> >> Dear People, >> >> >> >> I'm completely new here. >> >> >> >> Attached is a small piece of .c

Re: [Cocci] [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On Wed, Feb 14, 2018 at 11:22:38AM -0800, Kees Cook wrote: > > +/** > > + * kvmalloc_ab_c() - Allocate memory. > > Longer description, maybe? "Allocate a *b + c bytes of memory"? Done! > > + * @n: Number of elements. > > + * @size: Size of each element (should be constant). > > + * @c: Size of