3 This
document describes the options provided by Coccinelle. The options
4 have an impact on various phases of the semantic patch application
8 \item Selecting and parsing the semantic patch.
9 \item Selecting and parsing the C code.
10 \item Application of the semantic patch to the C code.
12 \item Generation of the result.
16 One can either initiate the complete process from step
1, or
17 to perform step
1 or step
2 individually.
19 Coccinelle has quite a lot of options. The most common usages are as
20 follows, for a semantic match
{\tt foo.cocci
}, a C file
{\tt foo.c
}, and a
21 directory
{\tt foodir
}:
24 \item {\tt spatch --parse-cocci foo.cocci
}: Check that the semantic patch
25 is syntactically correct.
26 \item {\tt spatch --parse-c foo.c
}: Check that the C file
27 is syntactically correct. The Coccinelle C parser tries to recover
28 during the parsing process, so if one function does not parse, it will
29 start up again with the next one. Thus, a parse error is often not a
30 cause for concern, unless it occurs in a function that is relevant to the
32 \item {\tt spatch --sp-file foo.cocci foo.c
}: Apply the semantic patch
{\tt
33 foo.cocci
} to the file
{\tt foo.c
} and print out any transformations as a
34 diff.
{\tt --sp-file
} is optional in this and the following cases.
35 \item {\tt spatch --sp-file foo.cocci foo.c --debug
}: The same as the
36 previous case, but print out some information about the matching process.
37 \item {\tt spatch --sp-file foo.cocci --dir foodir
}: Apply the semantic
38 patch
{\tt foo.cocci
} to all of the C files in the directory
{\tt foodir
}.
39 \item {\tt spatch --sp-file foo.cocci --dir foodir --include-headers
}: Apply
40 the semantic patch
{\tt foo.cocci
} to all of the C files and header files
41 in the directory
{\tt foodir
}.
44 In the rest of this
document, the options are annotated as follows:
46 \item \FilledBigDiamondshape: a basic option, that is most likely of
47 interest to all users.
48 \item \BigLowerDiamond: an option that is frequently used, often for better
49 understanding the effect of a semantic patch.
50 \item \BigDiamondshape: an option that is likely to be rarely used, but
51 whose effect is still comprehensible to a user.
52 \item An option with no annotation is likely of interest only to
56 \section{Selecting and parsing the semantic patch
}
58 \subsection{Standalone options
}
60 \normal{--parse-cocci $
\langle$file$
\rangle$
}{ Parse a semantic
61 patch file and print out some information about it.
}
63 \subsection{The semantic patch
}
65 \minimum{--sp-file $
\langle$file$
\rangle$, -c $
\langle$file$
\rangle$,
66 -cocci-file $
\langle$file$
\rangle$
}{ Specify the name of the file
67 containing the semantic patch. The file name should end in
{\tt .cocci
}.
68 All three options do the same thing. These options are optional. If they
69 are not used, the single file whose name ends in
\texttt{.cocci
} is
70 assoumed to be the name of the file containing the semantic patch.
}
72 \rare{--sp ``semantic patch string''
}{Specify a semantic match as a
73 command-line argument. See the section ``Command-line semantic match''
76 \subsection{Isomorphisms
}
78 \rare{--iso, --iso-file
}{ Specify a file containing isomorphisms to be used in
79 place of the standard one. Normally one should use the
{\tt using
}
80 construct within a semantic patch to specify isomorphisms to be used
{\em
81 in addition to
} the standard ones.
}
83 \rare{--iso-limit $
\langle$int$
\rangle$
} Limit the depth of application of
84 isomorphisms to the specified integer.
86 \rare{--no-iso-limit
} Put no limit on the number of times that
87 isomorphisms can be applied. This is the default.
89 \rare{--disable-iso
}{Disable a specific isomorphism from the command line.
90 This option can be specified multiple times.
}
92 \developer{--track-iso
}{ Gather information about isomorphism usage.
}
94 \developer{--profile-iso
}{ Gather information about the time required for
95 isomorphism expansion.
}
97 \subsection{Display options
}
99 \rare{--show-cocci
}{Show the semantic patch that is being processed before
100 expanding isomorphisms.
}
102 \rare{--show-SP
}{Show the semantic patch that is being processed after
103 expanding isomorphisms.
}
105 \rare{--show-ctl-text
}{ Show the representation
106 of the semantic patch in CTL.
}
108 \rare{--ctl-inline-let
}{ Sometimes
{\tt let
} is used to name
109 intermediate terms CTL representation. This option causes the let-bound
110 terms to be inlined at the point of their reference.
111 This option implicitly sets
{\bf --show-ctl-text
}.
}
113 \rare{--ctl-show-mcodekind
}{ Show
114 transformation information within the CTL representation
115 of the semantic patch. This option implicitly sets
{\bf --show-ctl-text
}.
}
117 \rare{--show-ctl-tex
}{ Create a LaTeX files showing the representation
118 of the semantic patch in CTL.
}
120 \section{Selecting and parsing the C files
}
122 \subsection{Standalone options
}
124 \normal{--parse-c $
\langle$file/dir$
\rangle$
}{ Parse a
{\tt .c
} file or all
125 of the
{\tt .c
} files in a directory. This generates information about
126 any parse errors encountered.
}
128 \normal{--parse-h $
\langle$file/dir$
\rangle$
}{ Parse a
{\tt .h
} file or all
129 of the
{\tt .h
} files in a directory. This generates information about
130 any parse errors encountered.
}
132 \normal{--parse-ch $
\langle$file/dir$
\rangle$
}{ Parse a
{\tt .c
} or
{\tt
133 .h
} file or all of the
{\tt .c
} or
{\tt .h
} files in a directory. This
134 generates information about any parse errors encountered.
}
136 \normal{--control-flow $
\langle$file$
\rangle$, --control-flow
137 $
\langle$file$
\rangle$:$
\langle$function$
\rangle$
}{ Print a control-flow
138 graph for all of the functions in a file or for a specific function in a
139 file. This requires
{\tt dot
} (http://www.graphviz.org/) and
{\tt gv
}.
}
141 \rare{--control-flow-to-file $
\langle$file$
\rangle$,
142 --control-flow-to-file
143 $
\langle$file$
\rangle$:$
\langle$function$
\rangle$
}{ Like --control-flow
144 but just puts the dot output in a file in the
{\em current
} directory.
145 For PATH/file.c, this produces file:xxx.dot for each (selected) function
148 \rare{--type-c $
\langle$file$
\rangle$
}{ Parse a C file and pretty-print a
149 version including type information.
}
151 \developer{--tokens-c $
\langle$file$
\rangle$
}{Prints the tokens in a C
154 \developer{--parse-unparse $
\langle$file$
\rangle$
}{Parse and then reconstruct
157 \developer{--compare-c $
\langle$file$
\rangle$ $
\langle$file$
\rangle$,
158 --compare-c-hardcoded
}{Compares one C file to another, or compare the
159 file tests/compare1.c to the file tests/compare2.c.
}
161 \developer{--test-cfg-ifdef $
\langle$file$
\rangle$
}{Do some special
162 processing of \#ifdef and display the resulting control-flow graph. This
163 requires
{\tt dot
} and
{\tt gv
}.
}
165 \developer{--test-attributes $
\langle$file$
\rangle$,
166 --test-cpp $
\langle$file$
\rangle$
}{
167 Test the parsing of cpp code and attributes, respectively.
}
169 \subsection{Selecting C files
}
171 An argument that ends in
{\tt .c
} is assumed to be a C file to process.
172 Normally, only one C file or one directory is specified. If multiple C
173 files are specified, they are treated in parallel,
{\em i.e.
}, the first
174 semantic patch rule is applied to all functions in all files, then the
175 second semantic patch rule is applied to all functions in all files, etc.
176 If a directory is specified then no files may be specified and only the
177 rightmost directory specified is used.
179 \normal{--include-headers
}{ This option causes header files to be processed
180 independently. This option only makes sense if a directory is specified
183 \normal{--use-glimpse
}{ Use a glimpse index to select the files to which
184 a semantic patch may be relevant. This option requires that a directory is
185 specified. The index may be created using the script
{\tt
186 coccinelle/scripts/ glimpseindex-cocci.sh
}. Glimpse is available at
187 http://webglimpse.net/. In conjunction with the option
{\bf --patch-cocci
}
188 this option prints the regular expression that will be passed to glimpse.
}
190 \normal{--use-idutils
}{ Use an id-utils index created using lid to select
191 the files to which a semantic patch may be relevant. This option
192 requires that a directory is specified. The index may be created using
193 the script
{\tt coccinelle/scripts/ idindex-cocci.sh
}. In conjunction
194 with the option
{\bf --patch-cocci
} this option prints the regular
195 expression that will be passed to glimpse.
}
197 \rare{--dir
}{ Specify a directory containing C files to process. A trailing
198 {\tt /
} is permitted on the directory name and has no impact on the
199 result. By default, the include path will be set to the ``include''
200 subdirectory of this directory. A different include path can be
201 specified using the option
{\bf -I
}.
{\bf --dir
} only considers the
202 rightmost directory in the argument list. This behavior is convenient
203 for creating a script that always works on a single directory, but allows
204 the user of the script to override the provided directory with another
205 one. Spatch collects the files in the directory using
{\tt find
} and
206 does not follow symbolic links.
}
208 \developer{--kbuild-info $
\langle$file$
\rangle$
}{ The specified file
209 contains information about which sets of files should be considered in
212 \developer{--disable-worth-trying-opt
}{Normally, a C file is only
213 processed if it contains some keywords that have been determined to be
214 essential for the semantic patch to match somewhere in the file. This
215 option disables this optimization and tries the semantic patch on all files.
}
217 \developer{--test $
\langle$file$
\rangle$
}{ A shortcut for running Coccinelle
218 on the semantic patch ``file
{\tt{.cocci
}}'' and the C file ``file
{\tt{.c
}}''.
}
220 \developer{--testall
}{A shortcut for running Coccinelle on all files in a
221 subdirectory
{\tt tests
} such that there are all of a
{\tt .cocci
} file, a
{\tt
222 .c
} file, and a
{\tt .res
} file, where the
{\tt .res
} contains the
225 \developer{--test-okfailed, --test-regression-okfailed
} Other options for
226 keeping track of tests that have succeeded and failed.
228 \developer{--compare-with-expected
}{Compare the result of applying
229 Coccinelle to file
{\tt{.c
}} to the file file
{\tt{.res
}} representing the
232 \developer{--expected-score-file $
\langle$file$
\rangle$
}{
233 which score file to compare with in the testall run
}
235 \subsection{Parsing C files
}
237 \rare{--show-c
}{Show the C code that is being processed.
}
239 \rare{--parse-error-msg
}{Show parsing errors in the C file.
}
241 \rare{--verbose-parsing
}{Show parsing errors in the C file, as well as
242 information about attempts to accomodate such errors. This implicitly
243 sets --parse-error-msg.
}
245 \rare{--type-error-msg
}{Show information about where the C type checker
246 was not able to determine the type of an expression.
}
248 \rare{--int-bits $
\langle$n$
\rangle$, --long-bits
249 $
\langle$n$
\rangle$
}{Provide integer size information. n is the number of
250 bits in an unsigned integer or unsigned long, respectively. If only the
251 option
{\bf --int-bits
} is used, unsigned longs will be assumed to have
252 twice as many bits as unsigned integers. If only the option
{\bf
253 -long-bits
} is used, unsigned ints will be assumed to have half as many
254 bits as unsigned integers. This information is only used in determining
255 the types of integer constants, according to the ANSI C standard (C89). If
256 neither is provided, the type of an integer constant is determined by the
257 sequence of ``u'' and ``l'' annotations following the constant. If there
258 is none, the constant is assumed to be a signed integer. If there is only
259 ``u'', the constant is assumed to be an unsigned integer, etc.
}
261 \rare{--no-loops
}{Drop back edges for loops. This may make a semantic
262 patch/match run faster, at the cost of not finding matches that wrap
265 \developer{--use-cache
}{Use preparsed versions of the C files that are
268 \developer{--cache-prefix
}{Specify the directory in which to store
269 preparsed versions of the C files. This sets
{--use-cache
}}
271 \developer{--cache-limit
}{Specify the maximum number of
272 preparsed C files to store. The cache is cleared of all files with names
273 ending in .ast-raw and .depend-raw on reaching this limit. Only
274 effective if --cache-prefix is used as well. This is most useful when
275 iteration is used to process a file multiple times within a single run of
278 \developer{--debug-cpp, --debug-lexer, --debug-etdt,
279 --debug-typedef
}{Various options for debugging the C parser.
}
281 \developer{--filter-msg, --filter-define-error,
282 --filter-passed-level
}{Various options for debugging the C parser.
}
284 \developer{--only-return-is-error-exit
}{In matching ``
{\tt{\ldots}}'' in
285 a semantic patch or when forall is specified, a rule must match all
286 control-flow paths starting from a node matching the beginning of the
287 rule. This is relaxed, however, for error handling code. Normally, error
288 handling code is considered to be a conditional with only a then branch
289 that ends in goto, break, continue, or return. If this option is set,
290 then only a then branch ending in a return is considered to be error
291 handling code. Usually a better strategy is to use
{\tt when strict
} in
292 the semantic patch, and then match explicitly the case where there is a
293 conditional whose then branch ends in a return.
}
295 \subsubsection*
{Macros and other preprocessor code
}
297 \normal{--macro-file $
\langle$file$
\rangle$
}{
298 Extra macro definitions to be taken into account when parsing the C
299 files. This uses the provided macro definitions in addition to those in
300 the default macro file.
}
302 \normal{--macro-file-builtins $
\langle$file$
\rangle$
}{
303 Builtin macro definitions to be taken into account when parsing the C
304 files. This causes the macro definitions provided in the default macro
305 file to be ignored and the ones in the specified file to be used instead.
}
307 \rare{--ifdef-to-if,-no-ifdef-to-if
}{
308 The option
{\bf --ifdef-to-if
}
309 represents an
{\tt \#ifdef
} in the source code as a conditional in the
310 control-flow graph when doing so represents valid code.
{\bf
311 -no-ifdef-to-if
} disables this feature.
{\bf --ifdef-to-if
} is the
315 \rare{--use-if0-code
}{ Normally code under \#if
0 is ignored. If this
316 option is set then the code is considered, just like the code under any
319 \developer{--noadd-typedef-root
}{This seems to reduce the scope of a
320 typedef declaration found in the C code.
}
322 \subsubsection*
{Include files
}
324 \normal{--recursive-includes, --all-includes, --local-includes,
325 --no-includes
}{ These options control which include files mentioned in a
326 C file are taken into account.
{\bf --recursive-includes
} indicates
327 that all included files mentioned in the .c file(s) or any included files
328 will be processed.
{\bf --all-includes
} indicates that all included
329 files mentioned in the .c file(s) will be processed.
{\bf
330 --local-includes
} indicates that only included files in the current
331 directory will be processed.
{\bf --no-includes
} indicates that no
332 included files will be processed. If the semantic patch contains type
333 specifications on expression metavariables, then the default is
{\bf
334 --local-includes
}. Otherwise the default is
{\bf --no-includes
}. At
335 most one of these options can be specified.
}
337 \normal{-I $
\langle$path$
\rangle$
}{ This option specifies a directory
338 in which to find non-local include files. This option can be used
341 \rare{--relax-include-path
}{This option when combined with --all-includes
342 causes the search for local
343 include files to consider the current directory, even if the include
344 patch specifies a subdirectory. This is really only useful for testing,
345 eg with the option
{\bf --testall
}}
347 \rare{--c++
}{Make an extremely minimal effort to parse C++ code. Currently,
348 this is limited to allowing identifiers to contain ``::'', tilde, and
349 template invocations. Consider testing your code first with spatch
350 --type-c to see if there are any type annotations in the code you are
351 interested in processing. If not, then it was probably not parsed.
}
353 \section{Application of the semantic patch to the C code
}
355 \subsection{Feedback at the rule level during the application of the
358 \normal{--show-bindings
}{
359 Show the environments with respect to which each rule is applied and the
360 bindings that result from each such application.
}
362 \normal{--show-dependencies
}{ Show the status (matched or unmatched) of the
363 rules on which a given rule depends.
{\bf --show-dependencies
} implicitly
364 sets
{\bf --show-bindings
}, as the values of the dependencies are
365 environment-specific.
}
367 \normal{--show-trying
}{
368 Show the name of each program element to which each rule is applied.
}
370 \normal{--show-transinfo
}{
371 Show information about each transformation that is performed.
372 The node numbers that are referenced are the number of the nodes in the
373 control-flow graph, which can be seen using the option
{\bf --control-flow
}
374 (the initial control-flow graph only) or the option
{\bf --show-flow
} (the
375 control-flow graph before and after each rule application).
}
377 \normal{--show-misc
}{Show some miscellaneous information.
}
379 \rare{--show-flow $
\langle$file$
\rangle$, --show-flow
380 $
\langle$file$
\rangle$:$
\langle$function$
\rangle$
} Show the control-flow
381 graph before and after the application of each rule.
383 \developer{--show-before-fixed-flow
}{This is similar to
{\bf
384 --show-flow
}, but shows a preliminary version of the control-flow graph.
}
386 \subsection{Feedback at the CTL level during the application of the
389 \normal{--verbose-engine
}{Show a trace of the matching of atomic terms to C
392 \rare{--verbose-ctl-engine
}{Show a trace of the CTL matching process.
393 This is unfortunately rather voluminous and not so helpful for someone
394 who is not familiar with CTL in general and the translation of SmPL into
395 CTL specifically. This option implicitly sets the option
{\bf
398 \rare{--graphical-trace
}{Create a pdf file containing the control flow
399 graph annotated with the various nodes matched during the CTL matching
400 process. Unfortunately, except for the most simple examples, the output
401 is voluminous, and so the option is not really practical for most
402 examples. This requires
{\tt dot
} (http://www.graphviz.org/) and
{\tt
405 \rare{--gt-without-label
}{The same as
{\bf --graphical-trace
}, but the PDF
406 file does not contain the CTL code.
}
408 \rare{--partial-match
}{
409 Report partial matches of the semantic patch on the C file. This can
410 be substantially slower than normal matching.
}
412 \rare{--verbose-match
}{
413 Report on when CTL matching is not applied to a function or other program
414 unit because it does not contain some required atomic pattern.
415 This can be viewed as a simpler, more efficient, but less informative
416 version of
{\bf --partial-match
}.
}
418 \subsection{Actions during the application of the semantic patch
}
420 \normal{-D rulename
}{Run the patch considering that the virtual rule
421 ``rulename'' is satisfied. Virtual rules should be declared at the
422 beginning of the semantic patch in a comma separated list following the
423 keyword virtual. Other rules can depend on the satisfaction or non
424 satifaction of these rules using the keyword
{\tt depends on
} in the
427 \normal{-D variable=value
}{Run the patch considering that the virtual
428 identifier metavariable ``variable'' is bound to ``value''. Any
429 identifier metavariable can be designated as being virtual by giving it
430 the rule name
{\tt virtual
}. An example is in demos/vm.coci
}
432 \rare{--allow-inconsistent-paths
}{Normally, a term that is transformed
433 should only be accessible from other terms that are matched by the
434 semantic patch. This option removes this constraint. Doing so, is
435 unsafe, however, because the properties that hold along the matched path
436 might not hold at all along the unmatched path.
}
438 \rare{--disallow-nested-exps
}{In an expression that contains repeated
439 nested subterms,
{\em e.g.
} of the form
{\tt f(f(x))
}, a pattern can
440 match a single expression in multiple ways, some nested inside others.
441 This option causes the matching process to stop immediately at the
442 outermost match. Thus, in the example
{\tt f(f(x))
}, the possibility
443 that the pattern
{\tt f(E)
}, with metavariable
{\tt E
}, matches with
{\tt
444 E
} as
{\tt x
} will not be considered.
}
446 \rare{--no-safe-expressions
}{normally, we check that an expression does
447 not match something earlier in the disjunction. But for large
448 disjunctions, this can result in a very big CTL formula. So this
449 option give the user the option to say he doesn't want this feature,
450 if that is the case.
}
452 \rare{--pyoutput coccilib.output.Gtk, --pyoutput coccilib.output.Console
}{
453 This controls whether Python output is sent to Gtk or to the console.
{\bf
454 --pyoutput coccilib.output.Console
} is the default. The Gtk option is
455 currently not well supported.
}
457 \developer{--loop
}{When there is ``
{\tt{\ldots}}'' in the semantic patch,
458 the CTL operator
{\sf AU
} is used if the current function does not
459 contain a loop, and
{\sf AW
} may be used if it does. This option causes
460 {\sf AW
} always to be used.
}
462 \rare{--ocaml-regexps
}{Use the regular expressions provided by the OCaml
463 \texttt{Str
} library. This is the default if the PCRE library is not
464 available. Otherwise PCRE regular expressions are used by default.
}
466 \developer{--steps $
\langle$int$
\rangle$
}{
467 This limits the number of steps performed by the CTL engine to the
468 specified number. This option is unsafe as it might cause a rule to fail
469 due to running out of steps rather than due to not matching.
}
471 \developer{--bench $
\langle$int$
\rangle$
}{This collects various information
472 about the operations performed during the CTL matching process.
}
474 % \developer{--popl, --popl-mark-all, --popl-keep-all-wits}{
475 % These options use a simplified version of the SmPL language. {\bf
476 % --popl-mark-all} and {\bf --popl-keep-all-wits} implicitly set {\bf
479 \section{Generation of the result
}
481 Normally, the only output is a diff printed to standard output, containing
482 the differences between the original code and the transformed code. If
483 stars are used in column
0 rather than
{\tt -
} and
{\tt +
}, then the
{\tt
484 -
} lines in the diff are the lines that matched the stars.
486 \normal{--keep-comments
}{Don't remove comments adjacent to removed code.
}
488 \normal{--linux-spacing, --smpl-spacing
}{Control the spacing within the code
489 added by the semantic patch. The option
{\bf --linux-spacing
} causes
490 spatch to follow the conventions of Linux, regardless of the spacing in
491 the semantic patch. This is the default. The option
{\bf
492 --smpl-spacing
} causes spatch to follow the spacing given in the semantic
493 patch, within individual lines.
}
495 \rare{-o $
\langle$file$
\rangle$
}{ This causes the transformed code to be
496 placed in the file
{\tt file
}. A diff is still printed to the standard
497 output. This option only makes sense when
{\tt -
} and
{\tt +
} are used.
}
499 \rare{--in-place
}{ Modify the input file to contain the transformed code.
500 A diff is still printed to the standard output. By default, the input
501 file is overwritten when using this option, with no backup. This option
502 only makes sense when
{\tt -
} and
{\tt +
} are used.
}
504 \rare{--backup-suffix
}{The suffix of the file to use in making a backup of
505 the original file(s). This suffix should include the leading ``.'', if
506 one is desired. This option only has an effect when the option
507 {\tt --in-place
} is also used.
}
509 \rare{--out-place
}{ Store the result of modifying the code in a .cocci-res
510 file. A diff is still printed to the standard output. This option only
511 makes sense when
{\tt -
} and
{\tt +
} are used.
}
513 \rare{--no-show-diff
}{ Normally, a diff between the original and transformed
514 code is printed on the standard output. This option causes this not to be
517 \rare{-U
}{ Set number of diff context lines.
}
519 \rare{--patch $
\langle$path$
\rangle$
}{The prefix of the pathname of the
520 directory or file name that should dropped from the diff line in the
521 generated patch. This is useful if you want to apply a patch only to a
522 subdirectory of a source code tree but want to create a patch that can be
523 applied at the root of the source code tree. An example could be
{\tt
524 spatch --sp-file foo.cocci --dir /var/linuxes/linux-next/drivers --patch
525 /var/linuxes/linux-next
}. A trailing
{\tt /
} is permitted on the
526 directory name and has no impact on the result.
}
528 \rare{--save-tmp-files
}{Coccinelle creates some temporary
529 files in
{\tt /tmp
} that it deletes after use. This option causes these
532 \developer{--debug-unparsing
}{Show some debugging information about the
533 generation of the transformed code. This has the side-effect of
534 deleting the transformed code.
}
537 \section{Other options
}
539 \subsection{Version information
}
541 \normal{--version
}{ The version of Coccinelle. No other options are
544 \normal{--date
}{ The date of the current version of Coccinelle. No other
545 options are allowed.
}
549 \minimum{--h, --shorthelp
}{ The most useful commands.
}
551 \minimum{--help, --help, --longhelp
}{ A complete listing of the available
554 \subsection{Controlling the execution of Coccinelle
}
556 \normal{--timeout $
\langle$int$
\rangle$
}{ The maximum time in seconds for
557 processing a single file.
}
559 \rare{--max $
\langle$int$
\rangle$
}{This option informs Coccinelle of the
560 number of instances of Coccinelle that will be run concurrently. This
561 option requires
{\bf --index
}. It is usually used with
{\bf --dir
}.
}
563 \rare{--index $
\langle$int$
\rangle$
}{This option informs Coccinelle of
564 which of the concurrent instances is the current one. This option
565 requires
{\bf --max
}.
}
567 \rare{--mod-distrib
}{When multiple instances of Coccinelle are run in
568 parallel, normally the first instance processes the first $n$ files, the
569 second instance the second $n$ files, etc. With this option, the files
570 are distributed among the instances in a round-robin fashion.
}
572 \developer{--debugger
}{Option for running Coccinelle from within the OCaml
575 \developer{--profile
}{ Gather timing information about the main Coccinelle
578 \developer{--disable-once
}{Print various warning messages every time some
579 condition occurs, rather than only once.
}
581 \subsection{Miscellaneous
}
583 \rare{--quiet
}{Suppress most output. This is the default.
}
585 %\developer{--pad, -hrule $\langle$dir$\rangle$, -xxx, -l1}{}
586 \developer{--pad, --xxx, --l1
}{}
591 %%% TeX-master: "main_options"
594 %%% ispell-local-dictionary: "american"