1.. SPDX-License-Identifier: CC-BY-4.0 2 3MISRA C deviations for Xen 4========================== 5 6The following is the list of MISRA C:2012 deviations for the Xen codebase that 7are not covered by a `SAF-x-safe` or `SAF-x-false-positive-<tool>` comment, as 8specified in docs/misra/documenting-violations.rst; the lack of 9such comments is usually due to the excessive clutter they would bring to the 10codebase or the impossibility to express such a deviation (e.g., if it's 11composed of several conditions). 12 13Deviations related to MISRA C:2012 Directives: 14---------------------------------------------- 15 16.. list-table:: 17 :header-rows: 1 18 19 * - Directive identifier 20 - Justification 21 - Notes 22 23 * - D4.3 24 - Accepted for the ARM64 codebase 25 - Tagged as `disapplied` for ECLAIR on any other violation report. 26 27 * - D4.3 28 - The inline asm in 'xen/arch/arm/arm64/lib/bitops.c' is tightly coupled 29 with the surronding C code that acts as a wrapper, so it has been decided 30 not to add an additional encapsulation layer. 31 - Tagged as `deliberate` for ECLAIR. 32 33 * - D4.10 34 - Files that are intended to be included more than once (and have 35 a comment that says this explicitly) do not need to conform to the 36 directive. 37 - Tagged as `safe` for ECLAIR. 38 39 * - D4.10 40 - There are autogenerated files that do not need to comply to the 41 directive. 42 - Tagged as `safe` for ECLAIR. Such files are: 43 - xen/include/generated/autoconf.h 44 45 * - D4.10 46 - Including multiple times a .c file is safe because every function or data item 47 it defines would in (the common case) be already defined. 48 Peer reviewed by the community. 49 - Tagged as `safe` for ECLAIR. 50 51Deviations related to MISRA C:2012 Rules: 52----------------------------------------- 53 54.. list-table:: 55 :header-rows: 1 56 57 * - Rule identifier 58 - Justification 59 - Notes 60 61 * - R2.1 62 - The compiler implementation guarantees that the unreachable code is 63 removed. Constant expressions and unreachable branches of if and switch 64 statements are expected. 65 - Tagged as `safe` for ECLAIR. 66 67 * - R2.1 68 - Unreachability caused by calls to the following functions or macros is 69 deliberate and there is no risk of code being unexpectedly left out. 70 - Tagged as `deliberate` for ECLAIR. Such macros are: 71 - BUG 72 - assert_failed 73 - __builtin_unreachable 74 - ASSERT_UNREACHABLE 75 76 * - R2.1 77 - Pure declarations, that is, declarations without initializations are not 78 executable, and therefore it is safe for them to be unreachable. The most 79 notable example of such a pattern being used in the codebase is that of 80 a variable declaration that should be available in all the clauses of a 81 switch statement. 82 - ECLAIR has been configured to ignore those statements. 83 84 * - R2.1 85 - The asm-offset files are not linked deliberately, since they are used to 86 generate definitions for asm modules. 87 - Tagged as `deliberate` for ECLAIR. 88 89 * - R2.1 90 - Calls to the `__builtin_unreachable()` function inside the expansion of 91 the `ASSERT_UNREACHABLE()` macro may cause a function to be marked as 92 non-returning. This behavior occurs only in configurations where 93 assertions are enabled. To address this, the `noreturn` property for 94 `__builtin_unreachable()` is overridden in these contexts, resulting in 95 the absence of reports that do not have an impact on safety, despite 96 being true positives. 97 Xen expects developers to ensure code remains safe and reliable in builds, 98 even when debug-only assertions like `ASSERT_UNREACHABLE() are removed. 99 100 * - R2.2 101 - Proving compliance with respect to Rule 2.2 is generally impossible: 102 see `<https://arxiv.org/abs/2212.13933>`_ for details. Moreover, peer 103 review gives us confidence that no evidence of errors in the program's 104 logic has been missed due to undetected violations of Rule 2.2, if any. 105 Testing on time behavior gives us confidence on the fact that, should the 106 program contain dead code that is not removed by the compiler, the 107 resulting slowdown is negligible. 108 - Project-wide deviation, tagged as `disapplied` for ECLAIR. 109 110 * - R2.6 111 - Labels deliberately marked as unused trough the pseudo-attribute 112 `__maybe_unused` are either the result of them not being in certain build 113 configurations, or as a deliberate practice (e.g., `unimplemented_insn`). 114 Given that the compiler is then entitled to remove them, the presence of 115 such labels poses no risks. 116 - Tagged as `deliberate` for ECLAIR. 117 118 * - R3.1 119 - Comments starting with '/\*' and containing hyperlinks are safe as they 120 are not instances of commented-out code. 121 - Tagged as `safe` for ECLAIR. 122 123 * - R5.3 124 - As specified in rules.rst, shadowing due to macros being used as macro 125 arguments is allowed, as it's deemed not at risk of causing developer 126 confusion. 127 - Tagged as `safe` for ECLAIR. So far, the following macros are deviated: 128 - READ_SYSREG and WRITE_SYSREG 129 - max_{t}? and min_{t}? 130 - read_[bwlq] and read_[bwlq]_relaxed 131 - per_cpu and this_cpu 132 - __emulate_2op and __emulate_2op_nobyte 133 - read_debugreg and write_debugreg 134 135 * - R5.5 136 - Macros expanding to their own name are allowed. 137 - Tagged as `deliberate` for ECLAIR. 138 139 * - R5.5 140 - Clashes between names of function-like macros and identifiers of 141 non-callable entities are allowed. 142 - Tagged as `deliberate` for ECLAIR. 143 144 * - R5.5 145 - Clashes between function names and macros are deliberate for string 146 handling functions since some architectures may want to use their own 147 arch-specific implementation. 148 - Tagged as `deliberate` for ECLAIR. 149 150 * - R5.5 151 - In libelf, clashes between macros and function names are deliberate and 152 needed to prevent the use of undecorated versions of memcpy, memset and 153 memmove. 154 - Tagged as `deliberate` for ECLAIR. 155 156 * - R5.5 157 - Clashes between bitops ('__test_and_set_bit', '__test_and_clear_bit', 158 '__test_and_change_bit', 'test_bit', 'set_bit', 'clear_bit', 'change_bit', 159 'test_and_set_bit', 'test_and_clear_bit', 'test_and_change_bit') 160 functions and macro names are intentional. These are necessary for error 161 handling and input validation to ensure that the size of the object being 162 referenced by the memory address (passed as an argument to the macro) 163 meets the minimum requirements for the bit operation. This prevents unsafe 164 operations on improperly sized data types that could lead to undefined 165 behavior or memory corruption. The macros encapsulate this conditional 166 logic into a single, reusable form, simplifying the code and avoiding 167 function call overhead. Also this bit operations API was inherited from 168 Linux and should be kept for familiarity. 169 - ECLAIR has been configured to ignore these macros. 170 171 * - R5.5 172 - Clashes between grant table ('update_gnttab_par', 'parse_gnttab_limit') 173 functions and macro names are intentional. These macros address 174 differences in argument count during compile-time, effectively discarding 175 unused 2nd and 3rd parameters to avoid warnings or errors related to them. 176 - ECLAIR has been configured to ignore these macros. 177 178 * - R5.6 179 - The type ret_t is deliberately defined multiple times depending on the 180 type of guest to service. 181 - Tagged as `deliberate` for ECLAIR. 182 183 * - R5.6 184 - On X86, some types are deliberately defined multiple times, depending on 185 the number of guest paging levels. 186 - Tagged as `deliberate` for ECLAIR. Such types are: 187 - guest_intpte_t 188 - guest_l[12]e_t 189 190 * - R5.6 191 - Some files are not subject to respect MISRA rules at 192 the moment, but, among these out-of-scope files, there are definitions 193 of typedef names that are already defined within in-scope files and 194 therefore, ECLAIR does report a violation since not all the files 195 involved in the violation are excluded from the analysis. 196 - Tagged as `deliberate` for ECLAIR. Such excluded files are: 197 - xen/include/efi/* 198 - xen/arch/*/include/asm/*/efibind.h 199 200 * - R7.1 201 - It is safe to use certain octal constants the way they are defined 202 in specifications, manuals, and algorithm descriptions. Such places 203 are marked safe with a /\* octal-ok \*/ in-code comment. 204 - Tagged as `safe` for ECLAIR. 205 206 * - R7.2 207 - Violations caused by __HYPERVISOR_VIRT_START are related to the 208 particular use of it done in xen_mk_ulong. 209 - Tagged as `deliberate` for ECLAIR. 210 211 * - R7.4 212 - Allow pointers of non-character type as long as the pointee is 213 const-qualified. 214 - ECLAIR has been configured to ignore these assignments. 215 216 * - R8.3 217 - The type ret_t is deliberately used and defined as int or long depending 218 on the architecture. 219 - Tagged as `deliberate` for ECLAIR. 220 221 * - R8.3 222 - Some files are not subject to respect MISRA rules at 223 the moment, but some entity from a file in scope is used; therefore 224 ECLAIR does report a violation, since not all the files involved in the 225 violation are excluded from the analysis. 226 - Tagged as `deliberate` for ECLAIR. Such excluded files are: 227 - xen/arch/x86/time.c 228 - xen/arch/x86/acpi/cpu_idle.c 229 - xen/arch/x86/mpparse.c 230 - xen/common/bunzip2.c 231 - xen/common/unlz4.c 232 - xen/common/unlzma.c 233 - xen/common/unlzo.c 234 - xen/common/unxz.c 235 - xen/common/unzstd.c 236 237 * - R8.3 238 - Parameter name "unused" (with an optional numeric suffix) is deliberate 239 and makes explicit the intention of not using such parameter within the 240 function. 241 - Tagged as `deliberate` for ECLAIR. 242 243 * - R8.4 244 - The definitions present in the files 'asm-offsets.c' for any architecture 245 are used to generate definitions for asm modules, and are not called by 246 C code. Therefore the absence of prior declarations is safe. 247 - Tagged as `safe` for ECLAIR. 248 249 * - R8.4 250 - The functions defined in the file xen/common/coverage/gcov_base.c are 251 meant to be called from gcc-generated code in a non-release build 252 configuration. Therefore, the absence of prior declarations is safe. 253 - Tagged as `safe` for ECLAIR. 254 255 * - R8.4 256 - Functions and variables used only by asm modules are marked with 257 the `asmlinkage` macro. Existing code may use a SAF-1-safe 258 textual deviation (see safe.json), but new code should not use 259 it. 260 - Tagged as `safe` for ECLAIR. 261 262 * - R8.4 263 - Some functions are excluded from non-debug build, therefore the absence 264 of declaration is safe. 265 - Tagged as `safe` for ECLAIR, such functions are: 266 - apei_read_mce() 267 - apei_check_mce() 268 - apei_clear_mce() 269 270 * - R8.4 271 - Given that bsearch and sort are defined with the attribute 'gnu_inline', 272 it's deliberate not to have a prior declaration. 273 See Section \"6.33.1 Common Function Attributes\" of \"GCC_MANUAL\" for 274 a full explanation of gnu_inline. 275 - Tagged as `deliberate` for ECLAIR. 276 277 * - R8.4 278 - first_valid_mfn is defined in this way because the current lack of NUMA 279 support in Arm and PPC requires it. 280 - Tagged as `deliberate` for ECLAIR. 281 282 * - R8.6 283 - The following variables are compiled in multiple translation units 284 belonging to different executables and therefore are safe. 285 286 - current_stack_pointer 287 - bsearch 288 - sort 289 - Tagged as `safe` for ECLAIR. 290 291 * - R8.6 292 - Declarations without definitions are allowed (specifically when the 293 definition is compiled-out or optimized-out by the compiler). 294 - Tagged as `deliberate` in ECLAIR. 295 296 * - R8.6 297 - The search procedure for Unix linkers is well defined, see ld(1) manual: 298 "The linker will search an archive only once, at the location where it 299 is specified on the command line. If the archive defines a symbol which 300 was undefined in some object which appeared before the archive on the 301 command line, the linker will include the appropriate file(s) from the 302 archive". 303 In Xen, thanks to the order in which file names appear in the build 304 commands, if arch-specific definitions are present, they get always 305 linked in before searching in the lib.a archive resulting from xen/lib. 306 - Tagged as `deliberate` for ECLAIR. 307 308 * - R8.10 309 - The gnu_inline attribute without static is deliberately allowed. 310 - Tagged as `deliberate` for ECLAIR. 311 312 * - R9.5 313 - The possibility of committing mistakes by specifying an explicit 314 dimension is higher than omitting the dimension, therefore all such 315 instances of violations are deviated. 316 - Project-wide deviation, tagged as `deliberate` for ECLAIR. 317 318 * - R10.1, R10.3, R10.4 319 - The value-preserving conversions of integer constants are safe. 320 - Tagged as `safe` for ECLAIR. 321 322 * - R10.1 323 - Shifting non-negative integers to the right is safe. 324 - Tagged as `safe` for ECLAIR. 325 326 * - R10.1 327 - Shifting non-negative integers to the left is safe if the result is still 328 non-negative. 329 - Tagged as `safe` for ECLAIR. 330 331 * - R10.1 332 - Bitwise logical operations on non-negative integers are safe. 333 - Tagged as `safe` for ECLAIR. 334 335 * - R10.1 336 - The implicit conversion to Boolean for logical operator arguments is 337 well-known to all Xen developers to be a comparison with 0. 338 - Tagged as `safe` for ECLAIR. 339 340 * - R10.1 341 - Xen only supports architectures where signed integers are representend 342 using two's complement and all the Xen developers are aware of this. For 343 this reason, bitwise operations are safe. 344 - Tagged as `safe` for ECLAIR. 345 346 * - R10.1 347 - Given the assumptions on the toolchain detailed in 348 docs/misra/C-language-toolchain.rst and the build flags used by the 349 project, it is deemed safe to use bitwise shift operators. 350 See automation/eclair_analysis/deviations.ecl for the full explanation. 351 - Tagged as `safe` for ECLAIR. 352 353 * - R10.1 354 - The macro ISOLATE_LSB encapsulates the well-known pattern (x & -x) 355 applied to unsigned integer values on 2's complement architectures 356 (i.e., all architectures supported by Xen), used to obtain a mask where 357 just the least significant nonzero bit of x is set. 358 If no bits are set, 0 is returned. 359 - Tagged as `safe` for ECLAIR. 360 361 * - R10.1 362 - Applying the unary minus operator to unsigned type(s) has a 363 semantics (wrap around) that is well-defined by the toolchains. 364 For this reason, the operation is safe. 365 - Tagged as `safe` for ECLAIR. 366 367 * - R11.1 368 - The conversion from a function pointer to unsigned long or (void \*) does 369 not lose any information, provided that the target type has enough bits 370 to store it. 371 - Tagged as `safe` for ECLAIR. 372 373 * - R11.1 374 - The conversion from a function pointer to a boolean has a well-known 375 semantics that do not lead to unexpected behaviour. 376 - Tagged as `safe` for ECLAIR. 377 378 * - R11.1 379 - The conversion from 'void noreturn (*)(...)' to 'void (*)(...)' is safe 380 because the semantics of the 'noreturn' attribute do not alter the calling 381 convention or behavior of the resulting code, parameters handling remain 382 consistent. 383 - Tagged as `safe` for ECLAIR. 384 385 * - R11.2 386 - The conversion from a pointer to an incomplete type to unsigned long 387 does not lose any information, provided that the target type has enough 388 bits to store it. 389 - Tagged as `safe` for ECLAIR. 390 391 * - R11.3 392 - Conversions to object pointers that have a pointee type with a smaller 393 (i.e., less strict) alignment requirement are safe. 394 - Tagged as `safe` for ECLAIR. 395 396 * - R11.6 397 - Conversions from and to integral types are safe, in the assumption that 398 the target type has enough bits to store the value. 399 See also Section \"4.7 Arrays and Pointers\" of \"GCC_MANUAL\" 400 - Tagged as `safe` for ECLAIR. 401 402 * - R11.6 403 - The conversion from a pointer to a boolean has a well-known semantics 404 that do not lead to unexpected behaviour. 405 - Tagged as `safe` for ECLAIR. 406 407 * - R11.8 408 - Violations caused by container_of are due to pointer arithmetic operations 409 with the provided offset. The resulting pointer is then immediately cast back to its 410 original type, which preserves the qualifier. This use is deemed safe. 411 Fixing this violation would require to increase code complexity and lower readability. 412 - Tagged as `safe` for ECLAIR. 413 414 * - R11.8 415 - Violations caused by function __hvm_copy occur when a const void 416 argument is passed, as the const qualifier is stripped. However, in such 417 cases, the function ensures that it does not modify the buffer 418 referenced by the argument, therefore, this use is deemed safe. Fixing 419 this violation would require to increase code complexity and lower 420 readability. 421 - Tagged as `safe` for ECLAIR. 422 423 * - R11.9 424 - __ACCESS_ONCE uses an integer, which happens to be zero, as a 425 compile time check. The typecheck uses a cast. The usage of zero or other 426 integers for this purpose is allowed. 427 - Tagged as `deliberate` for ECLAIR. 428 429 * - R12.2 430 - The width in bits of the C standard type is considered instead of 431 the width of the essential type of the left-hand operand of a shift 432 operator. This is safe because the occurrence of Undefined Behavior 433 only relates to the width of the C standard type, which is possibly 434 wider than its essential type. 435 - Project-wide deviation. 436 437 * - R13.5 438 - All developers and reviewers can be safely assumed to be well aware of 439 the short-circuit evaluation strategy for logical operators. 440 - Project-wide deviation; tagged as `disapplied` for ECLAIR. 441 442 * - R13.6 443 - On x86, macros alternative_v?call[0-9] use sizeof and typeof to check 444 that the argument types match the corresponding parameter ones. 445 - Tagged as `deliberate` for ECLAIR. 446 447 * - R13.6 448 - Anything, no matter how complicated, inside the BUILD_BUG_ON macro is 449 subject to a compile-time evaluation without relevant side effects." 450 - Tagged as `safe` for ECLAIR. 451 452 * - R14.2 453 - The severe restrictions imposed by this rule on the use of 'for' 454 statements are not counterbalanced by the presumed facilitation of the 455 peer review activity. 456 - Project-wide deviation; tagged as `disapplied` for ECLAIR. 457 458 * - R14.3 459 - The Xen team relies on the fact that invariant conditions of 'if' 460 statements and conditional operators are deliberate. 461 - Tagged as `deliberate` for ECLAIR. 462 463 * - R14.3 464 - Switches having a 'sizeof' operator as the condition are deliberate and 465 have limited scope. 466 - Tagged as `deliberate` for ECLAIR. 467 468 * - R14.3 469 - The use of an invariant size argument in {put,get}_unsafe_size and 470 array_access_ok, as defined in arch/x86(_64)?/include/asm/uaccess.h is 471 deliberate and is deemed safe. 472 - Tagged as `deliberate` for ECLAIR. 473 474 * - R14.4 475 - A controlling expression of 'if' and iteration statements having 476 integer, character or pointer type has a semantics that is well-known to 477 all Xen developers. 478 - Tagged as `deliberate` for ECLAIR. 479 480 * - R14.4 481 - The XEN team relies on the fact that the enum is_dying has the 482 constant with assigned value 0 act as false and the other ones as true, 483 therefore have the same behavior of a boolean. 484 - Tagged as `deliberate` for ECLAIR. 485 486 * - R16.2 487 - Complying with the Rule would entail a lot of code duplication in the 488 implementation of the x86 emulator, therefore it is deemed better to 489 leave such files as is. 490 - Tagged as `deliberate` for ECLAIR. 491 492 * - R16.3 493 - Statements that change the control flow (i.e., break, continue, goto, 494 return) and calls to functions that do not return the control back are 495 \"allowed terminal statements\". 496 - Tagged as `safe` for ECLAIR. 497 498 * - R16.3 499 - An if-else statement having both branches ending with one of the allowed 500 terminal statemets is itself an allowed terminal statements. 501 - Tagged as `safe` for ECLAIR. 502 503 * - R16.3 504 - An if-else statement having an always true condition and the true 505 branch ending with an allowed terminal statement is itself an allowed 506 terminal statement. 507 - Tagged as `safe` for ECLAIR. 508 509 * - R16.3 510 - A switch clause ending with a statement expression which, in turn, ends 511 with an allowed terminal statement (e.g., the expansion of 512 generate_exception()) is safe. 513 - Tagged as `safe` for ECLAIR. 514 515 * - R16.3 516 - A switch clause ending with a do-while-false the body of which, in turn, 517 ends with an allowed terminal statement (e.g., PARSE_ERR_RET()) is safe. 518 An exception to that is the macro ASSERT_UNREACHABLE() which is 519 effective in debug build only: a switch clause ending with 520 ASSERT_UNREACHABLE() is not considered safe. 521 - Tagged as `safe` for ECLAIR. 522 523 * - R16.3 524 - Switch clauses ending with pseudo-keyword \"fallthrough\" are safe. 525 - Tagged as `safe` for ECLAIR. 526 527 * - R16.3 528 - Switch clauses ending with failure method \"BUG()\" are safe. 529 - Tagged as `safe` for ECLAIR. 530 531 * - R16.3 532 - Existing switch clauses not ending with the break statement are safe if 533 an explicit comment indicating the fallthrough intention is present. 534 However, the use of such comments in new code is deprecated: 535 the pseudo-keyword "fallthrough" shall be used. 536 - Tagged as `safe` for ECLAIR. The accepted comments are: 537 - /\* fall through \*/ 538 - /\* fall through. \*/ 539 - /\* fallthrough \*/ 540 - /\* fallthrough. \*/ 541 - /\* Fall through \*/ 542 - /\* Fall through. \*/ 543 - /\* Fallthrough \*/ 544 - /\* Fallthrough. \*/ 545 546 * - R16.4 547 - Switch statements having a controlling expression of enum type 548 deliberately do not have a default case: gcc -Wall enables -Wswitch 549 which warns (and breaks the build as we use -Werror) if one of the enum 550 labels is missing from the switch. 551 - Tagged as `deliberate` for ECLAIR. 552 553 * - R16.4 554 - A switch statement with a single switch clause and no default label may 555 be used in place of an equivalent if statement if it is considered to 556 improve readability. 557 - Tagged as `deliberate` for ECLAIR. 558 559 * - R16.6 560 - A switch statement with a single switch clause and no default label may 561 be used in place of an equivalent if statement if it is considered to 562 improve readability. 563 - Tagged as `deliberate` for ECLAIR. 564 565 * - R17.1 566 - printf()-like functions are allowed to use the variadic features provided 567 by `stdarg.h`. 568 - Tagged as `deliberate` for ECLAIR. 569 570 * - R17.7 571 - Not using the return value of a function does not endanger safety if it 572 coincides with an actual argument. 573 - Tagged as `safe` for ECLAIR. Such functions are: 574 - __builtin_memcpy() 575 - __builtin_memmove() 576 - __builtin_memset() 577 - cpumask_check() 578 579 * - R18.2 580 - Subtractions between pointers where at least one of the operand is a 581 pointer to a symbol defined by the linker are safe. 582 - Tagged as `safe` for ECLAIR. 583 584 * - R18.2 585 - Subtraction between pointers encapsulated by macro page_to_mfn 586 are safe. 587 - Tagged as `safe` for ECLAIR. 588 589 * - R20.4 590 - The override of the keyword \"inline\" in xen/compiler.h is present so 591 that section contents checks pass when the compiler chooses not to 592 inline a particular function. 593 - Comment-based deviation. 594 595 * - R20.7 596 - Code violating Rule 20.7 is safe when macro parameters are used: 597 (1) as function arguments; 598 (2) as macro arguments; 599 (3) as array indices; 600 (4) as lhs in assignments; 601 (5) as initializers, possibly designated, in initalizer lists; 602 (6) as constant expressions of switch case labels. 603 - Tagged as `safe` for ECLAIR. 604 605 * - R20.7 606 - Violations due to the use of macros defined in files that are not 607 in scope for compliance are allowed, as that is imported code. 608 - Tagged as `safe` for ECLAIR. 609 610 * - R20.7 611 - To avoid compromising readability, the macros `alternative_(v)?call[0-9]` 612 are allowed not to parenthesize their arguments, as there are already 613 sanity checks in place. 614 - Tagged as `safe` for ECLAIR. 615 616 * - R20.7 617 - The macro `count_args_` is not compliant with the rule, but is not likely 618 to incur in the risk of being misused or lead to developer confusion, and 619 refactoring it to add parentheses breaks its functionality. 620 - Tagged as `safe` for ECLAIR. 621 622 * - R20.7 623 - The macros `{COMPILE,RUNTIME}_CHECK` defined in 624 `xen/include/xen/self-tests.h` are allowed not to parenthesize the "fn" 625 argument, to allow function-like macros to be tested as well as 626 functions. Given the specialized use of these macros and their limited 627 usage scope, omitting parentheses is deemed unlikely to cause issues. 628 - Tagged as `deliberate` for ECLAIR. 629 630 * - R20.7 631 - Problems related to operator precedence can not occur if the expansion 632 of the macro argument is surrounded by tokens '{', '}' and ';'. 633 - Tagged as `safe` for ECLAIR. 634 635 * - R20.12 636 - Variadic macros that use token pasting often employ the gcc extension 637 `ext_paste_comma`, as detailed in `C-language-toolchain.rst`, which is 638 not easily replaceable; macros that in addition perform regular argument 639 expansion on the same argument subject to the # or ## operators violate 640 the Rule if the argument is a macro. 641 - Tagged as `deliberate` for ECLAIR. 642 643 * - R20.12 644 - Macros that are used for runtime or build-time assertions contain 645 deliberate uses of an argument as both a regular argument and a 646 stringification token, to provide useful diagnostic messages. 647 - Tagged as `deliberate` for ECLAIR. 648 649 * - R20.12 650 - GENERATE_CASE is a local helper macro that allows some selected switch 651 statements to be more compact and readable. As such, the risk of 652 developer confusion in using such macro is deemed negligible. This 653 construct is deviated only in Translation Units that present a violation 654 of the Rule due to uses of this macro. 655 - Tagged as `deliberate` for ECLAIR. 656 657 * - R21.6 658 - Xen does not use the input/output functions provided by the C 659 Standard Library, but provides in source form its own implementation, 660 therefore any unspecified or undefined behavior associated to the 661 functions provided by the Standard Library does not apply. Any such 662 behavior that may exist in such functions is therefore under the 663 jurisdiction of other MISRA C guidelines. 664 - Tagged as `deliberate` for ECLAIR. 665 666 * - R21.9 667 - Xen does not use the `bsearch` and `qsort` functions provided by the C 668 Standard Library, but provides in source form its own implementation, 669 therefore any unspecified or undefined behavior associated to the 670 functions provided by the Standard Library does not apply. Any such 671 behavior that may exist in such functions is therefore under the 672 jurisdiction of other MISRA C rules. 673 - Project-wide deviation, tagged as `deliberate` for ECLAIR. 674 675 * - R21.10 676 - Xen does not use the facilities provided by the `\<time.h\>` provided by the C 677 Standard Library, but provides in source form its own implementation, 678 therefore any unspecified, undefined or implementation-defined behavior 679 associated to the functions provided by the Standard Library does not 680 apply. Any such behavior that may exist in such functions is therefore 681 under the jurisdiction of other MISRA C rules. 682 - Project-wide deviation, tagged as `deliberate` for ECLAIR. 683 684Other deviations: 685----------------- 686 687.. list-table:: 688 :header-rows: 1 689 690 * - Deviation 691 - Justification 692 693 * - do-while-0 and do-while-1 loops 694 - The do-while-0 and do-while-1 loops are well-recognized loop idioms used 695 by the Xen community and can therefore be used, even though they would 696 cause a number of violations in some instances. 697 698 * - while-0 and while-1 loops 699 - while-0 and while-1 are well-recognized loop idioms used by the Xen 700 community and can therefore be used, even though they would cause a 701 number of violations in some instances. 702