Re: [XEN PATCH v2 1/3] EFI: address a violation of MISRA C Rule 13.6

On 2024-10-08 07:59, Jan Beulich wrote: On 02.10.2024 08:54, Roberto Bagnara wrote: On 2024-10-02 08:09, Jan Beulich wrote: On 01.10.2024 23:36, Stefano Stabellini wrote: On Tue, 1 Oct 2024, Jan Beulich wrote: On 01.10.2024 07:25, Roberto Bagnara wrote: On 2024-09-30 15:07, Jan Beulich

Re: [XEN PATCH v2 1/3] EFI: address a violation of MISRA C Rule 13.6

On 2024-10-02 08:09, Jan Beulich wrote: On 01.10.2024 23:36, Stefano Stabellini wrote: On Tue, 1 Oct 2024, Jan Beulich wrote: On 01.10.2024 07:25, Roberto Bagnara wrote: On 2024-09-30 15:07, Jan Beulich wrote: On 30.09.2024 14:49, Federico Serafini wrote: guest_handle_ok()'s expa

Re: [XEN PATCH v2 1/3] EFI: address a violation of MISRA C Rule 13.6

On 2024-09-30 15:07, Jan Beulich wrote: On 30.09.2024 14:49, Federico Serafini wrote: guest_handle_ok()'s expansion contains a sizeof() involving its first argument which is guest_handle_cast(). The expansion of the latter, in turn, contains a variable initialization. Since MISRA considers the

Re: [RFC PATCH] xen: Remove -Wdeclaration-after-statement

On 09/08/24 21:25, Stefano Stabellini wrote: Adding Roberto Does MISRA have a view on this? I seem to remember this is discouraged? As far as I know, there is nothing in MISRA C against or in favor of mixing declaration with statements. The only (slightly) relevant guideline is advisory Rule

Re: [PATCH] xen: Use -Wuninitialized and -Winit-self

On 2024-01-05 07:56, Jan Beulich wrote: On 04.01.2024 21:43, Roberto Bagnara wrote: On 2024-01-04 15:33, Andrew Cooper wrote: On 04/01/2024 1:41 pm, Jan Beulich wrote: On 28.12.2023 20:39, Andrew Cooper wrote: The use of uninitialised data is undefined behaviour. At -O2 with trivial

Re: [PATCH] xen: Use -Wuninitialized and -Winit-self

On 2024-01-04 15:33, Andrew Cooper wrote: On 04/01/2024 1:41 pm, Jan Beulich wrote: On 28.12.2023 20:39, Andrew Cooper wrote: The use of uninitialised data is undefined behaviour. At -O2 with trivial examples, both Clang and GCC delete the variable, and in the case of a function return, the ca

Violations of mandatory MISRA C:2012 Rule 19.1 in X86_64 build

Hi there. Mandatory Rule 19.1 (An object shall not be assigned or copied to an overlapping object) is directly targeted at two undefined behaviors, one of which is the subject of 6.5.16.1p3, namely: If the value being stored in an object is read from another object that overlaps in any way

[XEN PATCH v3] docs/misra: document the C dialect and translation toolchain assumptions.

This document specifies the C language dialect used by Xen and the assumptions Xen makes on the translation toolchain. Signed-off-by: Roberto Bagnara Changes in V2: - Clarified several entries. - Removed entry about the use of the undefined escape sequence \m. Changes in V3: - Removed

Re: [XEN PATCH v2] docs/misra: document the C dialect and translation toolchain assumptions.

On 20/06/23 17:05, Jan Beulich wrote: On 20.06.2023 14:10, Roberto Bagnara wrote: + * - Token pasting of ',' and __VA_ARGS__ + - ARM64, X86_64 + - See Section "6.21 Macros with a Variable Number of Arguments" of GCC_MANUAL. + + * - No arguments for '...

Re: [XEN PATCH v2] docs/misra: document the C dialect and translation toolchain assumptions.

On 21/06/23 12:27, Jan Beulich wrote: On 20.06.2023 14:10, Roberto Bagnara wrote: + * - static function is used in an inline function with external linkage + - ARM64, X86_64 + - Non-documented GCC extension. An inline function with external linkage + can be inlined everywhere

Re: [XEN PATCH v2] docs/misra: document the C dialect and translation toolchain assumptions.

On 20/06/23 16:56, Jan Beulich wrote: On 20.06.2023 14:10, Roberto Bagnara wrote: + * - Arithmetic operator on void type + - ARM64, X86_64 + - See Section "6.24 Arithmetic on void- and Function-Pointers" of GCC_MANUAL." The first line is misleading - we don&#

Re: [XEN PATCH v2] docs/misra: document the C dialect and translation toolchain assumptions.

On 20/06/23 16:52, Jan Beulich wrote: On 20.06.2023 14:10, Roberto Bagnara wrote: + * - Non-standard tokens + - ARM64, X86_64 + - _Static_assert: + see Section "2.1 C Language" of GCC_MANUAL. + asm, __asm__: + see Sections "6.48 Alternate Keyw

[XEN PATCH v2] docs/misra: document the C dialect and translation toolchain assumptions.

This document specifies the C language dialect used by Xen and the assumptions Xen makes on the translation toolchain. Signed-off-by: Roberto Bagnara --- docs/misra/C-language-toolchain.rst | 478 1 file changed, 478 insertions(+) create mode 100644 docs/misra/C

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On 16/06/23 22:43, Stefano Stabellini wrote: On Fri, 16 Jun 2023, Roberto Bagnara wrote: + * - Implicit conversion from a pointer to an incompatible pointer + - ARM64, X86_64 + - Non-documented GCC extension. Is this related to -Wincompatible-pointer-types? In my opinion, this

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On 19/06/23 13:47, Jan Beulich wrote: On 19.06.2023 12:53, Roberto Bagnara wrote: On 19/06/23 09:54, Jan Beulich wrote: On 16.06.2023 17:54, Roberto Bagnara wrote: On 16/06/23 01:26, Stefano Stabellini wrote: On Thu, 15 Jun 2023, Roberto Bagnara wrote: + static function is used in an

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On 19/06/23 09:54, Jan Beulich wrote: On 16.06.2023 17:54, Roberto Bagnara wrote: On 16/06/23 01:26, Stefano Stabellini wrote: On Thu, 15 Jun 2023, Roberto Bagnara wrote: + * - Unspecified escape sequence is encountered in a character constant or a string literal token + - X86_64

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On 19/06/23 09:54, Jan Beulich wrote: On 16.06.2023 17:54, Roberto Bagnara wrote: On 16/06/23 01:26, Stefano Stabellini wrote: On Thu, 15 Jun 2023, Roberto Bagnara wrote: + static function is used in an inline function with external linkage: + non-documented GCC extension. I

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On 16/06/23 01:26, Stefano Stabellini wrote: On Thu, 15 Jun 2023, Roberto Bagnara wrote: This document specifies the C language dialect used by Xen and the assumptions Xen makes on the translation toolchain. Signed-off-by: Roberto Bagnara Thanks Roberto for the amazing work of research and

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On 16/06/23 12:03, Jan Beulich wrote: On 16.06.2023 09:45, Roberto Bagnara wrote: On 16/06/23 08:53, Jan Beulich wrote: On 16.06.2023 01:26, Stefano Stabellini wrote: + * - Unspecified escape sequence is encountered in a character constant or a string literal token + - X86_64

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On 16/06/23 08:53, Jan Beulich wrote: On 16.06.2023 01:26, Stefano Stabellini wrote: On Thu, 15 Jun 2023, Roberto Bagnara wrote: I have a few comments below, mostly to clarify the description of some of the less documented GCC extensions, for the purpose of having all community members be able

[XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

This document specifies the C language dialect used by Xen and the assumptions Xen makes on the translation toolchain. Signed-off-by: Roberto Bagnara --- docs/misra/C-language-toolchain.rst | 465 1 file changed, 465 insertions(+) create mode 100644 docs/misra/C

Re: [PATCH] xen/evtchn: Purge ERROR_EXIT{,_DOM}()

On 13/06/23 19:45, Andrew Cooper wrote: On 13/06/2023 6:39 pm, Julien Grall wrote: Hi, On 13/06/2023 17:22, Andrew Cooper wrote: These are disliked specifically by MISRA, but they also interfere with code Please explicitly name the rule. I can't remember it off the top of my head. Stefano

Re: [PATCH v2] docs/misra: new rules addition

On 12/06/23 11:50, Jan Beulich wrote: On 12.06.2023 11:34, Roberto Bagnara wrote: On 12/06/23 09:33, Jan Beulich wrote: On 09.06.2023 19:45, Stefano Stabellini wrote: @@ -143,6 +163,12 @@ existing codebase are work-in-progress. - Octal constants shall not be used

Re: [PATCH v2] docs/misra: new rules addition

On 12/06/23 09:33, Jan Beulich wrote: On 09.06.2023 19:45, Stefano Stabellini wrote: @@ -133,6 +146,13 @@ existing codebase are work-in-progress. headers (xen/include/public/) are allowed to retain longer identifiers for backward compatibility. + * - `Rule 6.1

Re: [PATCH] docs/misra: new rules addition

On 09/06/23 10:46, Jan Beulich wrote: On 08.06.2023 13:02, Roberto Bagnara wrote: On 07/06/23 23:53, Stefano Stabellini wrote: On Wed, 7 Jun 2023, Jan Beulich wrote: + * - `Rule 5.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_06.c>`_ + - Re

Re: Xen reliance on non-standard GCC features

On 07/06/23 09:39, Jan Beulich wrote: On 05.06.2023 15:26, Roberto Bagnara wrote: On 05/06/23 11:28, Jan Beulich wrote: On 05.06.2023 07:28, Roberto Bagnara wrote: You are right: here are a few examples for U2: xen/arch/arm/cpuerrata.c:92.12-92.35: empty initializer list (ill-formed for the

Re: [PATCH] docs/misra: new rules addition

Hi there. Please see below. On 07/06/23 23:53, Stefano Stabellini wrote: On Wed, 7 Jun 2023, Jan Beulich wrote: + * - `Rule 5.6 `_ + - Required + - A typedef name shall be a unique identifier +

Re: Xen reliance on non-standard GCC features

On 05/06/23 11:28, Jan Beulich wrote: On 05.06.2023 07:28, Roberto Bagnara wrote: U1) Use of _Static_assert in C99 mode. U2) Empty initialization lists, both in C99 mode (ARM64 and X86_64) and C18 mode (only X86_64). U3) Returning void expressions. As per above, tiny extensions like

Re: Xen reliance on non-standard GCC features

On 05/06/23 10:58, Andrew Cooper wrote: On 05/06/2023 6:28 am, Roberto Bagnara wrote: U10) \m escape sequence. Is this an undocumented GCC extension or just a typo? Where are you seeing this? The only examples I see are in asm macros, and they're all parameter substitutions.

Re: Xen reliance on non-standard GCC features

On 05/06/23 09:35, Jan Beulich wrote: On 05.06.2023 07:28, Roberto Bagnara wrote: Finally, Xen seems to rely on explicitly undefined behavior, namely C99 UB 58: "A structure or union is defined as containing no named members (6.7.2.1)." All instances but one occur via macro BUILD_B

Xen reliance on non-standard GCC features

Hi there. It appears Xen uses lots of GCC features that are outside the C99 standard. Some of them are documented GNU extensions to the language. Some of them seem not to be documented, so they do not qualify as language extensions (at least, not as far as the spirit and letter of functional-saf

Re: MISRA C Rule 20.7 disambiguation

On 2022-12-09 23:46, Stefano Stabellini wrote: Eclair marks it as a violation too. Eclair thinks "nr" needs parenthesis. Roberto, we have already discussed how the comma operator "," being the lower precedence doesn't require extra parenthesis. Roberto, what's your take on the [] square brakets?

Re: [PATCH 0/7] Fix MISRA C 2012 Rule 20.7 violations

Hi Xenia. Please see below. On 9/26/22 10:50, Xenia Ragiadakou wrote: On 9/18/22 16:02, Roberto Bagnara wrote: The question is on the interpretation of Rule 20.7. Are parenthesis required by Rule 20.7 in the following cases: - macro parameters used as function arguments  > [...]  > -

Re: [PATCH 0/7] Fix MISRA C 2012 Rule 20.7 violations

On 03/09/22 02:52, Stefano Stabellini wrote: +Roberto I think we need Roberto's advice on Rule 20.7. (Full thread below.) Hi there, sorry for the delay: I missed this message. Please see below, where I took the freedom of rearranging the cases. The question is on the interpretation of Rule 2

Re: [PATCH 0/9] MISRA C 2012 8.1 rule fixes

int_t" to write, e.g., const lib_int_t r = strncmp(...); The lib_int_t typedef can be used with a suitable tool configuration, just as I mentioned one would do with size_t. Kind regards, Roberto On 23/06/22 09:51, Jan Beulich wrote: On 23.06.2022 09:37, Roberto Bagnara wrote: Rul

Re: [PATCH 0/9] MISRA C 2012 8.1 rule fixes

Hi there. Rule 8.1 only applies to C90 code, as all the violating instances are syntax errors in C99 and later versions of the language. So, the following line does not contain a violation of Rule 8.1: unsigned x; It does contain a violation of Directive 4.6, though, whose correct handling

Re: MISRA C meeting tomorrow, was: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC

On 09/06/22 09:04, Jan Beulich wrote: On 09.06.2022 03:20, Stefano Stabellini wrote: Finally, for Rule 13.2, I updated the link to ECLAIR's results. There are a lot more violations than just 4, but I don't know if they are valid or false positives. I've picked just the one case in xen/common/e

Re: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC

On 07/06/22 04:17, Stefano Stabellini wrote: > # Rule 9.1 "The value of an object with automatic storage duration shall not be read before it has been set" > > The question is whether -Wuninitalised already covers this case or not. > I think it does. > > Eclair is reporting a few issues where var

Re: [PATCH 1/3] x86/p2m.h: Add include guards

On 17/05/22 17:38, Jan Beulich wrote: On 09.05.2022 14:24, Andrew Cooper wrote: Spotted by Eclair MISRA scanner. I'm sorry, but what exactly was it that the scanner spotted? It was actually deliberate to introduce this file without guards. I'm of the general opinion that (private) headers not

Re: ECLAIR Xen x86 results and progress

On 09/05/22 21:55, Stefano Stabellini wrote: On Mon, 9 May 2022, Bertrand Marquis wrote: On 6 May 2022, at 17:31, Stefano Stabellini wrote: Hi all, Roberto kindly provided the ECLAIR x86 results: https://eclairit.com:8443/job/XEN/Target=X86_64,agent=public/lastSuccessfulBuild/eclair/ Click

Re: Invalid _Static_assert expanded from HASH_CALLBACKS_CHECK

Hi Jan. Please see below. On 25/05/21 10:58, Jan Beulich wrote: On 24.05.2021 06:29, Roberto Bagnara wrote: I stumbled upon parsing errors due to invalid uses of _Static_assert expanded from HASH_CALLBACKS_CHECK where the tested expression is not constant, as mandated by the C standard

Invalid _Static_assert expanded from HASH_CALLBACKS_CHECK

;"); | ~^~ $ Finally, I think this can be easily avoided: instead of initializing a static const with a constant expression and then static-asserting the static const, just static-assert the constant initializer. Kind regards, Roberto Bagnara