Lines Matching refs:not

24 Line length is recommended to be not more than 80 characters, including comments.
29 The above is recommendation, and not a hard limit.
61 The SPDX licences identifier is sufficient, a file should not contain
113 Do not ``#define`` or declare names except with the standard DPDK prefix: ``RTE_``.
166 …Exceptions may be made for cases where code is conditionally not compiled for the purposes of lint…
168 * For short conditionally compiled regions, a closing comment should not be used.
275 In declarations, do not put any whitespace between asterisks and adjacent tokens, except for tokens…
287 * Do not use uppercase letters - either in the form of ALL_UPPERCASE, or CamelCase - in variable na…
317 Uses of ``bool`` in structures are not preferred as is wastes space and
318 it's also not clear as to what type size the bool is. A preferred use of
351 whitelist' is not allowed.
396 Typedefs are problematic because they do not properly hide their underlying type;
403 Note that #defines used instead of typedefs also are problematic (since they do not propagate the p…
404 For example, ``#define pint int *`` does not work as expected, while ``typedef int *pint`` does wor…
434 * Indentation is a hard tab, that is, a tab character, not a sequence of spaces,
440 * Do not put any spaces before a tab for indentation.
443 …ion as to whether the second line of the control statement forms part of the statement body or not.
469 * Do not add whitespace at the end of a line.
471 * Do not add whitespace or a blank line at the end of a file.
478 * Do not use braces (``{`` and ``}``) for control statements with zero or just a single statement, …
509 * Braces that are not necessary should be left out.
525 * Do not use spaces after function names.
539 * Unary operators do not require spaces, binary operators do.
540 * Do not use parentheses unless they are required for precedence or unless the statement is confusi…
563 * Be careful to not obfuscate the code by initializing variables in the declarations, only the last…
565 * Do not use function calls in initializers, except for ``const`` variables.
580 * Casts and sizeof statements are not followed by a space.
582 The redundant parenthesis rules do not apply to sizeof(var) instances.
591 * Functions local to one source module should be declared static, and should not be prototyped unle…
595 * Do not use the ``__P`` macro.
598 * Do not use uppercase letters - either in the form of ALL_UPPERCASE, or CamelCase - in function na…
620 …Unlike function definitions, the function prototypes do not need to place the function return type…
635 * Do not declare functions inside other functions.
638 * Old-style (K&R) function declaration should not be used, use ANSI function declarations instead a…
662 …Use NULL instead of ``(type *)0`` or ``(type *)NULL``, except where the compiler does not know the…
672 * Do not use ! for tests unless it is a boolean, for example, use:
686 …ry, the alternative error approach may be used where the negative value is not -1 but is instead `…
688 * For functions where no error is possible, the function type should be ``void`` not ``int``.
689 * Routines returning ``void *`` should not have their return values cast to any pointer type.
695 The above rule about not typecasting ``void *`` applies to malloc, as well as to DPDK functions.
697 * Values in return statements should not be enclosed in parentheses.
725 RTE_LOG(WARNING, my_logtype2, "this is a debug level message (not displayed)\n");
729 RTE_LOG(DEBUG, my_logtype1, "debug level message (not displayed)\n");
735 …er builtin and allow the developer to indicate if the branch is likely to be taken or not. Example:
766 The ``asm`` and ``volatile`` keywords do not have underscores. The AT&T syntax should be used.
779 * Forever loops are done with for statements, not while statements.
905 also be set to explain to the user why the component is not being built.
910 if not is_linux
943 found, and, if not, the ``build`` variable should be set to ``false``.
964 not missing any include statements for dependent headers.
971 As with ``headers`` option above, except that the files are not checked
982 it does not need to be specified here.
997 consistently with the library, not the directory
1007 This variable should be used when a library is not to be built i.e. when
1008 ``build`` is set to "false", to specify the reason why a library will not be