[XEN PATCH v2 0/3] xen: address violations of MISRA C Rule 13.6

[XEN PATCH v2 0/3] xen: address violations of MISRA C Rule 13.6

[Federico Serafini]

Address remaining violations of Rule 13.6 and tag it as clean.

Federico Serafini (3):
  EFI: address violations of MISRA C Rule 13.6
  xen/gnttab: address violations of MISRA C Rule 13.6
  automation/eclair: tag Rule 13.6 as clean

 automation/eclair_analysis/ECLAIR/tagging.ecl |  1 +
 xen/common/compat/grant_table.c               | 15 +++++++++------
 xen/common/efi/runtime.c                      | 12 ++++++++++--
 3 files changed, 20 insertions(+), 8 deletions(-)

-- 
2.43.0

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

[Federico Serafini]

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 initialization (even of a local variable)
a side effect, the chain of expansions mentioned above violates
MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
contain any expression which has potential side effect).

Refactor the code to address the rule violation.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
Changes in v2:
- better description.
---
 xen/common/efi/runtime.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index d03e5c90ce..acf08dcaa3 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -250,14 +250,20 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
         info->cfg.addr = __pa(efi_ct);
         info->cfg.nent = efi_num_ct;
         break;
+
     case XEN_FW_EFI_VENDOR:
+    {
+        XEN_GUEST_HANDLE_PARAM(CHAR16) vendor_name =
+            guest_handle_cast(info->vendor.name, CHAR16);
+
         if ( !efi_fw_vendor )
             return -EOPNOTSUPP;
+
         info->vendor.revision = efi_fw_revision;
         n = info->vendor.bufsz / sizeof(*efi_fw_vendor);
-        if ( !guest_handle_okay(guest_handle_cast(info->vendor.name,
-                                                  CHAR16), n) )
+        if ( !guest_handle_okay(vendor_name, n) )
             return -EFAULT;
+
         for ( i = 0; i < n; ++i )
         {
             if ( __copy_to_guest_offset(info->vendor.name, i,
@@ -267,6 +273,8 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
                 break;
         }
         break;
+    }
+
     case XEN_FW_EFI_MEM_INFO:
         for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
         {
-- 
2.43.0

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

[Jan Beulich]

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 initialization (even of a local variable)
> a side effect, the chain of expansions mentioned above violates
> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
> contain any expression which has potential side effect).

I'm afraid I need to ask for clarification of terminology and alike here.
While the Misra doc has a section on Persistent Side Effects in its
Glossary appendix, what constitutes a side effect from its pov isn't
really spelled out anywhere. Which in turn raises the question whether it
is indeed Misra (and not just Eclair) which deems initialization a side
effect. This is even more so relevant as 13.6 talks of only expressions,
yet initializers fall under declarations (in turn involving an expression
on the rhs of the equal sign).

All the same of course affects patch 2 then, too.

Jan

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

[Roberto Bagnara]

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 initialization (even of a local variable)
>> a side effect, the chain of expansions mentioned above violates
>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
>> contain any expression which has potential side effect).
> 
> I'm afraid I need to ask for clarification of terminology and alike here.
> While the Misra doc has a section on Persistent Side Effects in its
> Glossary appendix, what constitutes a side effect from its pov isn't
> really spelled out anywhere. Which in turn raises the question whether it
> is indeed Misra (and not just Eclair) which deems initialization a side
> effect. This is even more so relevant as 13.6 talks of only expressions,
> yet initializers fall under declarations (in turn involving an expression
> on the rhs of the equal sign).
> 
> All the same of course affects patch 2 then, too.

MISRA C leaves the definition of "side effect" to the C Standard.
E.g., C18 5.1.2.3p2:

   Accessing a volatile object, modifying an object, modifying a file,
   or calling a function that does any of those operations are all
   side effects,[omitted irrelevant footnote reference] which are
   changes in the state of the execution environment.

The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
indirectly confirms that initialization is always a side effect.

Kind regards,

    Roberto

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

[Jan Beulich]

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 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 initialization (even of a local variable)
>>> a side effect, the chain of expansions mentioned above violates
>>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
>>> contain any expression which has potential side effect).
>>
>> I'm afraid I need to ask for clarification of terminology and alike here.
>> While the Misra doc has a section on Persistent Side Effects in its
>> Glossary appendix, what constitutes a side effect from its pov isn't
>> really spelled out anywhere. Which in turn raises the question whether it
>> is indeed Misra (and not just Eclair) which deems initialization a side
>> effect. This is even more so relevant as 13.6 talks of only expressions,
>> yet initializers fall under declarations (in turn involving an expression
>> on the rhs of the equal sign).
>>
>> All the same of course affects patch 2 then, too.
> 
> MISRA C leaves the definition of "side effect" to the C Standard.
> E.g., C18 5.1.2.3p2:
> 
>    Accessing a volatile object, modifying an object, modifying a file,
>    or calling a function that does any of those operations are all
>    side effects,[omitted irrelevant footnote reference] which are
>    changes in the state of the execution environment.
> 
> The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
> indirectly confirms that initialization is always a side effect.

Hmm, that's interesting: There's indeed an example with an initializer
there. Yet to me the text you quote from the C standard does not say
that initialization is a side effect - it would be "modifying an
object" aiui, yet ahead of initialization being complete the object
doesn't "exist" imo, and hence can be "modified" only afterwards.

Jan

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

[Stefano Stabellini]

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 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 initialization (even of a local variable)
> >>> a side effect, the chain of expansions mentioned above violates
> >>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
> >>> contain any expression which has potential side effect).
> >>
> >> I'm afraid I need to ask for clarification of terminology and alike here.
> >> While the Misra doc has a section on Persistent Side Effects in its
> >> Glossary appendix, what constitutes a side effect from its pov isn't
> >> really spelled out anywhere. Which in turn raises the question whether it
> >> is indeed Misra (and not just Eclair) which deems initialization a side
> >> effect. This is even more so relevant as 13.6 talks of only expressions,
> >> yet initializers fall under declarations (in turn involving an expression
> >> on the rhs of the equal sign).
> >>
> >> All the same of course affects patch 2 then, too.
> > 
> > MISRA C leaves the definition of "side effect" to the C Standard.
> > E.g., C18 5.1.2.3p2:
> > 
> >    Accessing a volatile object, modifying an object, modifying a file,
> >    or calling a function that does any of those operations are all
> >    side effects,[omitted irrelevant footnote reference] which are
> >    changes in the state of the execution environment.
> > 
> > The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
> > indirectly confirms that initialization is always a side effect.
> 
> Hmm, that's interesting: There's indeed an example with an initializer
> there. Yet to me the text you quote from the C standard does not say
> that initialization is a side effect - it would be "modifying an
> object" aiui, yet ahead of initialization being complete the object
> doesn't "exist" imo, and hence can be "modified" only afterwards.

Hi Jan,

I feel it's becoming a bit too philosophical. Since there's some room
for interpretation and only two violations left to address, I believe
it's best to stick with the stricter interpretation of the definition.
Therefore, I'd proceed with this series in its current form.

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

[Jan Beulich]

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 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 initialization (even of a local variable)
>>>>> a side effect, the chain of expansions mentioned above violates
>>>>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
>>>>> contain any expression which has potential side effect).
>>>>
>>>> I'm afraid I need to ask for clarification of terminology and alike here.
>>>> While the Misra doc has a section on Persistent Side Effects in its
>>>> Glossary appendix, what constitutes a side effect from its pov isn't
>>>> really spelled out anywhere. Which in turn raises the question whether it
>>>> is indeed Misra (and not just Eclair) which deems initialization a side
>>>> effect. This is even more so relevant as 13.6 talks of only expressions,
>>>> yet initializers fall under declarations (in turn involving an expression
>>>> on the rhs of the equal sign).
>>>>
>>>> All the same of course affects patch 2 then, too.
>>>
>>> MISRA C leaves the definition of "side effect" to the C Standard.
>>> E.g., C18 5.1.2.3p2:
>>>
>>>    Accessing a volatile object, modifying an object, modifying a file,
>>>    or calling a function that does any of those operations are all
>>>    side effects,[omitted irrelevant footnote reference] which are
>>>    changes in the state of the execution environment.
>>>
>>> The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
>>> indirectly confirms that initialization is always a side effect.
>>
>> Hmm, that's interesting: There's indeed an example with an initializer
>> there. Yet to me the text you quote from the C standard does not say
>> that initialization is a side effect - it would be "modifying an
>> object" aiui, yet ahead of initialization being complete the object
>> doesn't "exist" imo, and hence can be "modified" only afterwards.
> 
> I feel it's becoming a bit too philosophical. Since there's some room
> for interpretation and only two violations left to address, I believe
> it's best to stick with the stricter interpretation of the definition.
> Therefore, I'd proceed with this series in its current form.

Proceeding with the series in its current form may be okay (as you say,
you view the changes as readability improvements anyway), but imo the
interpretation needs settling on no matter what. In fact even for these
two patches it may affect what their descriptions ought to say (would
be nice imo to avoid permanently recording potentially misleading
information by committing as is). And of course clarity would help
dealing with future instances that might appear. I take it you realize
that if someone had submitted a patch adding code similar to the
original forms of what's being altered here, it would be relatively
unlikely for a reviewer to spot the issue. IOW here we're making
ourselves heavily dependent upon Eclair spotting (supposed) issues,
adding extra work and delays for such changes to go in.

Jan

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

[Roberto Bagnara]

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 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 initialization (even of a local variable)
>>>>>> a side effect, the chain of expansions mentioned above violates
>>>>>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
>>>>>> contain any expression which has potential side effect).
>>>>>
>>>>> I'm afraid I need to ask for clarification of terminology and alike here.
>>>>> While the Misra doc has a section on Persistent Side Effects in its
>>>>> Glossary appendix, what constitutes a side effect from its pov isn't
>>>>> really spelled out anywhere. Which in turn raises the question whether it
>>>>> is indeed Misra (and not just Eclair) which deems initialization a side
>>>>> effect. This is even more so relevant as 13.6 talks of only expressions,
>>>>> yet initializers fall under declarations (in turn involving an expression
>>>>> on the rhs of the equal sign).
>>>>>
>>>>> All the same of course affects patch 2 then, too.
>>>>
>>>> MISRA C leaves the definition of "side effect" to the C Standard.
>>>> E.g., C18 5.1.2.3p2:
>>>>
>>>>     Accessing a volatile object, modifying an object, modifying a file,
>>>>     or calling a function that does any of those operations are all
>>>>     side effects,[omitted irrelevant footnote reference] which are
>>>>     changes in the state of the execution environment.
>>>>
>>>> The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
>>>> indirectly confirms that initialization is always a side effect.
>>>
>>> Hmm, that's interesting: There's indeed an example with an initializer
>>> there. Yet to me the text you quote from the C standard does not say
>>> that initialization is a side effect - it would be "modifying an
>>> object" aiui, yet ahead of initialization being complete the object
>>> doesn't "exist" imo, and hence can be "modified" only afterwards.
>>
>> I feel it's becoming a bit too philosophical. Since there's some room
>> for interpretation and only two violations left to address, I believe
>> it's best to stick with the stricter interpretation of the definition.
>> Therefore, I'd proceed with this series in its current form.
> 
> Proceeding with the series in its current form may be okay (as you say,
> you view the changes as readability improvements anyway), but imo the
> interpretation needs settling on no matter what. In fact even for these
> two patches it may affect what their descriptions ought to say (would
> be nice imo to avoid permanently recording potentially misleading
> information by committing as is). And of course clarity would help
> dealing with future instances that might appear. I take it you realize
> that if someone had submitted a patch adding code similar to the
> original forms of what's being altered here, it would be relatively
> unlikely for a reviewer to spot the issue. IOW here we're making
> ourselves heavily dependent upon Eclair spotting (supposed) issues,
> adding extra work and delays for such changes to go in.

You can do two things to obtain a second opinion:

1) Use the MISRA forum (here is the link to the forum
    section devoted to the side-effect rules of MISRA C:2012
    and MISRA C:2023 (https://forum.misra.org.uk/forumdisplay.php?fid=168).
    The MISRA C Working Group will, in due course, provide
    you with an official answer to your questions about what,
    for the interpretation of Rule 13.6, has to be considered
    a side effect.

2) Reach out to your ISO National Body and try to obtain
    an official answer from ISO/IEC JTC1/SC22/WG14 (the
    international standardization working group for the
    programming language C) to your questions about what the
    C Standard considers to be side effects.

Kind regards,

    Roberto

Roberto Bagnara, Ph.D.

Software Verification Expert and Evangelist, BUGSENG (http://bugseng.com)
Professor of Computer Science, University of Parma
Member, ISO/IEC JTC1/SC22/WG14 - C Standardization Working Group
Member, MISRA C Working Group

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

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 5251 bytes --]

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 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 initialization (even of a local variable)
>>>>>>> a side effect, the chain of expansions mentioned above violates
>>>>>>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
>>>>>>> contain any expression which has potential side effect).
>>>>>>
>>>>>> I'm afraid I need to ask for clarification of terminology and alike here.
>>>>>> While the Misra doc has a section on Persistent Side Effects in its
>>>>>> Glossary appendix, what constitutes a side effect from its pov isn't
>>>>>> really spelled out anywhere. Which in turn raises the question whether it
>>>>>> is indeed Misra (and not just Eclair) which deems initialization a side
>>>>>> effect. This is even more so relevant as 13.6 talks of only expressions,
>>>>>> yet initializers fall under declarations (in turn involving an expression
>>>>>> on the rhs of the equal sign).
>>>>>>
>>>>>> All the same of course affects patch 2 then, too.
>>>>>
>>>>> MISRA C leaves the definition of "side effect" to the C Standard.
>>>>> E.g., C18 5.1.2.3p2:
>>>>>
>>>>>     Accessing a volatile object, modifying an object, modifying a file,
>>>>>     or calling a function that does any of those operations are all
>>>>>     side effects,[omitted irrelevant footnote reference] which are
>>>>>     changes in the state of the execution environment.
>>>>>
>>>>> The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
>>>>> indirectly confirms that initialization is always a side effect.
>>>>
>>>> Hmm, that's interesting: There's indeed an example with an initializer
>>>> there. Yet to me the text you quote from the C standard does not say
>>>> that initialization is a side effect - it would be "modifying an
>>>> object" aiui, yet ahead of initialization being complete the object
>>>> doesn't "exist" imo, and hence can be "modified" only afterwards.
>>>
>>> I feel it's becoming a bit too philosophical. Since there's some room
>>> for interpretation and only two violations left to address, I believe
>>> it's best to stick with the stricter interpretation of the definition.
>>> Therefore, I'd proceed with this series in its current form.
>>
>> Proceeding with the series in its current form may be okay (as you say,
>> you view the changes as readability improvements anyway), but imo the
>> interpretation needs settling on no matter what. In fact even for these
>> two patches it may affect what their descriptions ought to say (would
>> be nice imo to avoid permanently recording potentially misleading
>> information by committing as is). And of course clarity would help
>> dealing with future instances that might appear. I take it you realize
>> that if someone had submitted a patch adding code similar to the
>> original forms of what's being altered here, it would be relatively
>> unlikely for a reviewer to spot the issue. IOW here we're making
>> ourselves heavily dependent upon Eclair spotting (supposed) issues,
>> adding extra work and delays for such changes to go in.
> 
> You can do two things to obtain a second opinion:
> 
> 1) Use the MISRA forum (here is the link to the forum
>     section devoted to the side-effect rules of MISRA C:2012
>     and MISRA C:2023 (https://forum.misra.org.uk/forumdisplay.php?fid=168).
>     The MISRA C Working Group will, in due course, provide
>     you with an official answer to your questions about what,
>     for the interpretation of Rule 13.6, has to be considered
>     a side effect.
> 
> 2) Reach out to your ISO National Body and try to obtain
>     an official answer from ISO/IEC JTC1/SC22/WG14 (the
>     international standardization working group for the
>     programming language C) to your questions about what the
>     C Standard considers to be side effects.

I took the latter route, and to my (positive) surprise I got back an answer
the same day. There was a request for someone to confirm, but so far I didn't
see further replies. Since this is a German institution I raised the question
in German and got back an answer in German (attached); I've tried my best to
translate this without falsifying anything, but I've omitted non-technical
parts:

"Initialization of an object is never a side effect of the initialization
by itself. Of course expressions used for initialization can themselves have
side effects on other objects.

@Andreas: Do you agree? C after all has a far simpler object model than C++.
The (potential) change in object representation (i.e. the bytes underlying
the object) is not a side effect of object initialization, but its primary
purpose."

Further for Misra she added a reference to a Swiss person, but I think with
Bugseng we have sufficient expertise there.

Jan

[-- Attachment #2: AW: Klarstellung zu ISO/IEC JTC1/SC22/WG14.eml --]
[-- Type: message/rfc822, Size: 11099 bytes --]

From: Daniela Engert <dani@ngrt.de>
To: "Wellhöfer, Johannes" <Johannes.Wellhoefer@din.de>, "jbeulich@suse.com" <jbeulich@suse.com>
Cc: Andreas Weis <der_ghulbus@ghulbus-inc.de>
Subject: Re: AW: Klarstellung zu ISO/IEC JTC1/SC22/WG14
Date: Wed, 2 Oct 2024 15:31:12 +0200 (CEST)
Message-ID: <1532591295.2404908.1727875872865@com4.strato.de>

Hallo zusammen,

bitte nicht wundern, aber sobald ich "Ingenieur" rieche, bin ich sofort beim "Du" (bin ja selber eine).
Mein Hauptfokus liegt zwar auf C++, und C ist für mich ein "Seiteneffekt", aber diese Frage kann ich vermutlich ebenfalls beantworten:

Die Initialisierung eines Objekts ist niemals ein Seiteneffekt der Initialisierung von sich selbst. In den Expressions, welche zur Initialisierung evaluiert werden, können jedoch sehr wohl Seiteneffekte in anderen Objekten auftreten.

@Andreas: kannst du dem zustimmen? C hat ja ein sehr viel einfacheres Objektmodell als C++. Die (potentielle) Änderung der Objektrepräsentation (d.h. die Bytes, welche das Objekt hinterlegen) ist ja kein Seiteneffekt der Objektinitialisierung, sondern sein primärer Zweck.

Wenn es um MISRA geht, wäre sicherlich P. Sommerlad der richtige Ansprechpartner (https://sommerlad.ch/). Ansonsten tagt das WG14 Komittee gerade, große Teile der WG14 Tafelrunde sind versammelt, Robert Seacord ist sein Chair.

lG Daniela



> Wellhöfer, Johannes <johannes.wellhoefer@din.de> hat am 02.10.2024 15:02 CEST geschrieben:
> 
> 
> Danke Manuela, fürs weiterleiten.
>  
>  Sehr geehrter Herr Beulich, 
>  
>  vielen Dank für Ihre Anfrage. Ich habe Frau Engert hier mit in den Emailverlauf genommen. Sie arbeitet als deutsche Expertin in der JTC1/SC22/WG14 mit.
> 
> @Daniela Engert können Sie Herrn Beulich mit seiner Frage (unten im Verlauf gelb markiert) weiterhelfen?
>  
>  Mit freundlichen Grüßen
> 
> Johannes Wellhöfer
> Er/Sein
> Projektmanager
> DIN-Normenausschuss Informationstechnik und Anwendungen (NIA)
> DIN Deutsches Institut für Normung e. V. – Industrie und Informationstechnik (DIN – NuS IIT IuA)
> 
> LinkedIn (https://www.linkedin.com/in/johannes-wellhoefer/) | T +49 30 2601-2455 | F +49 30 2601-4-2455 | M +49 174 2007820
> LinkedIn-Kanal des Normenausschusses für Informationstechnik und Anwendungen (https://www.linkedin.com/showcase/din-nia/)
> 
> 
> 
> 
> Ab sofort kostenlos: Der Normungs-Monitor (https://www.din.de/de/din-und-seine-partner/presse/mitteilungen/ab-januar-kostenlos-der-normungs-monitor-983794)
> Unkompliziert zu Normungsprojekten Ihrer Branche auf dem Laufenden bleiben
> 
> 
> Folgen Sie uns auf	 https://twitter.com/DIN_Norm	 https://www.linkedin.com/company/din-ev	 https://www.youtube.com/user/DINBerlin	
> 
> DIN Deutsches Institut für Normung e. V., Am DIN-Platz, Burggrafenstraße 6, 10787 Berlin; www.din.de (http://www.din.de/)} Registergericht: AG Berlin-Charlottenburg, VR 288 B; Präsident: Ulrich B. Stoll; Vorstand: Christoph Winterhalter (Vorsitzender), Daniel Schmidt;
> Der Inhalt dieser E-Mail (einschließlich Anhängen) ist vertraulich. Falls Sie diese E-Mail versehentlich erhalten haben, löschen Sie sie bitte und informieren den Absender. The contents of this e-mail (including attachments) are confidential. If you received this e-mail in error, please delete it and notify the sender.
> -----Ursprüngliche Nachricht-----
>  Von: Tillack-Lübke, Manuela <Manuela.Tillack-luebke@din.de> 
>  Gesendet: Mittwoch, 2. Oktober 2024 12:09
>  An: Wellhöfer, Johannes <Johannes.Wellhoefer@din.de>
>  Betreff: WG: Klarstellung zu ISO/IEC JTC1/SC22/WG14
> 
> Lieber Johannes,
> 
> zuständigkeitshalber bitte ich Dich um Beantwortung der unten angefügten Anfrage. Vielen Dank.
> 
> 
> Mit besten Grüßen
> 
> Manuela
> AP A. 634
> - 2419
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: info@din.de <info@din.de>
> Gesendet: Mittwoch, 2. Oktober 2024 10:17
> An: DIN Info <DIN-Info@din.de>
> Betreff: Klarstellung zu ISO/IEC JTC1/SC22/WG14
> 
> Guten Tag,
> 
> folgende Nachricht wurde auf https://www.din.de/de an Sie geschickt.
> 
> Guten Tag,
> 
> im Zusammenhang mit Misra C:2012 ist eine Interpretationsfrage zum C99 Standard (ISO/IEC 9899:TC3) aufgetaucht. Zur Klärung wurde ich an den ISO National Body verwiesen, der - soweit ich feststellen kann - Sie sind.
> 
> Die eigentliche Frage betrifft "side effects": Fällt die Initialisierung eines Objekts auch darunter?
> 
> In der Hoffnung, dass Sie uns bei der Klärung behilflich sein können, möglicherweise auch durch Verweis an eine andere geeignete Stelle, vielen Dank im Voraus,
> Jan Beulich
> 
> Herr Jan Beulich
> jbeulich@suse.com

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

[Roberto Bagnara]

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 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 initialization (even of a local variable)
>>>>>>>> a side effect, the chain of expansions mentioned above violates
>>>>>>>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
>>>>>>>> contain any expression which has potential side effect).
>>>>>>>
>>>>>>> I'm afraid I need to ask for clarification of terminology and alike here.
>>>>>>> While the Misra doc has a section on Persistent Side Effects in its
>>>>>>> Glossary appendix, what constitutes a side effect from its pov isn't
>>>>>>> really spelled out anywhere. Which in turn raises the question whether it
>>>>>>> is indeed Misra (and not just Eclair) which deems initialization a side
>>>>>>> effect. This is even more so relevant as 13.6 talks of only expressions,
>>>>>>> yet initializers fall under declarations (in turn involving an expression
>>>>>>> on the rhs of the equal sign).
>>>>>>>
>>>>>>> All the same of course affects patch 2 then, too.
>>>>>>
>>>>>> MISRA C leaves the definition of "side effect" to the C Standard.
>>>>>> E.g., C18 5.1.2.3p2:
>>>>>>
>>>>>>      Accessing a volatile object, modifying an object, modifying a file,
>>>>>>      or calling a function that does any of those operations are all
>>>>>>      side effects,[omitted irrelevant footnote reference] which are
>>>>>>      changes in the state of the execution environment.
>>>>>>
>>>>>> The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
>>>>>> indirectly confirms that initialization is always a side effect.
>>>>>
>>>>> Hmm, that's interesting: There's indeed an example with an initializer
>>>>> there. Yet to me the text you quote from the C standard does not say
>>>>> that initialization is a side effect - it would be "modifying an
>>>>> object" aiui, yet ahead of initialization being complete the object
>>>>> doesn't "exist" imo, and hence can be "modified" only afterwards.
>>>>
>>>> I feel it's becoming a bit too philosophical. Since there's some room
>>>> for interpretation and only two violations left to address, I believe
>>>> it's best to stick with the stricter interpretation of the definition.
>>>> Therefore, I'd proceed with this series in its current form.
>>>
>>> Proceeding with the series in its current form may be okay (as you say,
>>> you view the changes as readability improvements anyway), but imo the
>>> interpretation needs settling on no matter what. In fact even for these
>>> two patches it may affect what their descriptions ought to say (would
>>> be nice imo to avoid permanently recording potentially misleading
>>> information by committing as is). And of course clarity would help
>>> dealing with future instances that might appear. I take it you realize
>>> that if someone had submitted a patch adding code similar to the
>>> original forms of what's being altered here, it would be relatively
>>> unlikely for a reviewer to spot the issue. IOW here we're making
>>> ourselves heavily dependent upon Eclair spotting (supposed) issues,
>>> adding extra work and delays for such changes to go in.
>>
>> You can do two things to obtain a second opinion:
>>
>> 1) Use the MISRA forum (here is the link to the forum
>>      section devoted to the side-effect rules of MISRA C:2012
>>      and MISRA C:2023 (https://forum.misra.org.uk/forumdisplay.php?fid=168).
>>      The MISRA C Working Group will, in due course, provide
>>      you with an official answer to your questions about what,
>>      for the interpretation of Rule 13.6, has to be considered
>>      a side effect.
>>
>> 2) Reach out to your ISO National Body and try to obtain
>>      an official answer from ISO/IEC JTC1/SC22/WG14 (the
>>      international standardization working group for the
>>      programming language C) to your questions about what the
>>      C Standard considers to be side effects.
> 
> I took the latter route, and to my (positive) surprise I got back an answer
> the same day. There was a request for someone to confirm, but so far I didn't
> see further replies. Since this is a German institution I raised the question
> in German and got back an answer in German (attached); I've tried my best to
> translate this without falsifying anything, but I've omitted non-technical
> parts:
> 
> "Initialization of an object is never a side effect of the initialization
> by itself. Of course expressions used for initialization can themselves have
> side effects on other objects.
> 
> @Andreas: Do you agree? C after all has a far simpler object model than C++.
> The (potential) change in object representation (i.e. the bytes underlying
> the object) is not a side effect of object initialization, but its primary
> purpose."
> 
> Further for Misra she added a reference to a Swiss person, but I think with
> Bugseng we have sufficient expertise there.

Unfortunately, the (translation of the) answer you received adds
confusion to previous confusion: who answered has highlighted the
"side" part of the term, which is indeed relevant in computer science,
but not for the C standard.  To the point that the same argument could
be used to deny that ++i has a side effect because the increment is
the "primary" effect...

Part of the confusion is maybe in the the following paragraph Jan
wrote earlier:

 > Hmm, that's interesting: There's indeed an example with an initializer
 > there. Yet to me the text you quote from the C standard does not say
 > that initialization is a side effect - it would be "modifying an
 > object" aiui, yet ahead of initialization being complete the object
 > doesn't "exist" imo, and hence can be "modified" only afterwards.

In C, it is not true that the object does not exist ahead of
initialization.  Try the following:

extern int f(int* p);

int main() {
   int i = f(&i);
}

Kind regards,

    Roberto

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

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 7450 bytes --]

On Tue, Oct 08, 2024 at 02:49:52PM +0200, Roberto Bagnara wrote:
> 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 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 initialization (even of a local variable)
> > > > > > > > > a side effect, the chain of expansions mentioned above violates
> > > > > > > > > MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
> > > > > > > > > contain any expression which has potential side effect).
> > > > > > > > 
> > > > > > > > I'm afraid I need to ask for clarification of terminology and alike here.
> > > > > > > > While the Misra doc has a section on Persistent Side Effects in its
> > > > > > > > Glossary appendix, what constitutes a side effect from its pov isn't
> > > > > > > > really spelled out anywhere. Which in turn raises the question whether it
> > > > > > > > is indeed Misra (and not just Eclair) which deems initialization a side
> > > > > > > > effect. This is even more so relevant as 13.6 talks of only expressions,
> > > > > > > > yet initializers fall under declarations (in turn involving an expression
> > > > > > > > on the rhs of the equal sign).
> > > > > > > > 
> > > > > > > > All the same of course affects patch 2 then, too.
> > > > > > > 
> > > > > > > MISRA C leaves the definition of "side effect" to the C Standard.
> > > > > > > E.g., C18 5.1.2.3p2:
> > > > > > > 
> > > > > > >      Accessing a volatile object, modifying an object, modifying a file,
> > > > > > >      or calling a function that does any of those operations are all
> > > > > > >      side effects,[omitted irrelevant footnote reference] which are
> > > > > > >      changes in the state of the execution environment.
> > > > > > > 
> > > > > > > The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
> > > > > > > indirectly confirms that initialization is always a side effect.
> > > > > > 
> > > > > > Hmm, that's interesting: There's indeed an example with an initializer
> > > > > > there. Yet to me the text you quote from the C standard does not say
> > > > > > that initialization is a side effect - it would be "modifying an
> > > > > > object" aiui, yet ahead of initialization being complete the object
> > > > > > doesn't "exist" imo, and hence can be "modified" only afterwards.
> > > > > 
> > > > > I feel it's becoming a bit too philosophical. Since there's some room
> > > > > for interpretation and only two violations left to address, I believe
> > > > > it's best to stick with the stricter interpretation of the definition.
> > > > > Therefore, I'd proceed with this series in its current form.
> > > > 
> > > > Proceeding with the series in its current form may be okay (as you say,
> > > > you view the changes as readability improvements anyway), but imo the
> > > > interpretation needs settling on no matter what. In fact even for these
> > > > two patches it may affect what their descriptions ought to say (would
> > > > be nice imo to avoid permanently recording potentially misleading
> > > > information by committing as is). And of course clarity would help
> > > > dealing with future instances that might appear. I take it you realize
> > > > that if someone had submitted a patch adding code similar to the
> > > > original forms of what's being altered here, it would be relatively
> > > > unlikely for a reviewer to spot the issue. IOW here we're making
> > > > ourselves heavily dependent upon Eclair spotting (supposed) issues,
> > > > adding extra work and delays for such changes to go in.
> > > 
> > > You can do two things to obtain a second opinion:
> > > 
> > > 1) Use the MISRA forum (here is the link to the forum
> > >      section devoted to the side-effect rules of MISRA C:2012
> > >      and MISRA C:2023 (https://forum.misra.org.uk/forumdisplay.php?fid=168).
> > >      The MISRA C Working Group will, in due course, provide
> > >      you with an official answer to your questions about what,
> > >      for the interpretation of Rule 13.6, has to be considered
> > >      a side effect.
> > > 
> > > 2) Reach out to your ISO National Body and try to obtain
> > >      an official answer from ISO/IEC JTC1/SC22/WG14 (the
> > >      international standardization working group for the
> > >      programming language C) to your questions about what the
> > >      C Standard considers to be side effects.
> > 
> > I took the latter route, and to my (positive) surprise I got back an answer
> > the same day. There was a request for someone to confirm, but so far I didn't
> > see further replies. Since this is a German institution I raised the question
> > in German and got back an answer in German (attached); I've tried my best to
> > translate this without falsifying anything, but I've omitted non-technical
> > parts:
> > 
> > "Initialization of an object is never a side effect of the initialization
> > by itself. Of course expressions used for initialization can themselves have
> > side effects on other objects.
> > 
> > @Andreas: Do you agree? C after all has a far simpler object model than C++.
> > The (potential) change in object representation (i.e. the bytes underlying
> > the object) is not a side effect of object initialization, but its primary
> > purpose."
> > 
> > Further for Misra she added a reference to a Swiss person, but I think with
> > Bugseng we have sufficient expertise there.
> 
> Unfortunately, the (translation of the) answer you received adds
> confusion to previous confusion: who answered has highlighted the
> "side" part of the term, which is indeed relevant in computer science,
> but not for the C standard.  To the point that the same argument could
> be used to deny that ++i has a side effect because the increment is
> the "primary" effect...
> 
> Part of the confusion is maybe in the the following paragraph Jan
> wrote earlier:
> 
> > Hmm, that's interesting: There's indeed an example with an initializer
> > there. Yet to me the text you quote from the C standard does not say
> > that initialization is a side effect - it would be "modifying an
> > object" aiui, yet ahead of initialization being complete the object
> > doesn't "exist" imo, and hence can be "modified" only afterwards.
> 
> In C, it is not true that the object does not exist ahead of
> initialization.  Try the following:
> 
> extern int f(int* p);
> 
> int main() {
>   int i = f(&i);
> }

This is interesting discussion, but I don't think it needs to block
anything. The proposed change doesn't violate any other rule/code style,
and I'd argue it's more readable. Taking more strict interpretation in
this case doesn't really hurt. I already acked this patch.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jan Beulich]

On 08.10.2024 14:49, Roberto Bagnara wrote:
> 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 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 initialization (even of a local variable)
>>>>>>>>> a side effect, the chain of expansions mentioned above violates
>>>>>>>>> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
>>>>>>>>> contain any expression which has potential side effect).
>>>>>>>>
>>>>>>>> I'm afraid I need to ask for clarification of terminology and alike here.
>>>>>>>> While the Misra doc has a section on Persistent Side Effects in its
>>>>>>>> Glossary appendix, what constitutes a side effect from its pov isn't
>>>>>>>> really spelled out anywhere. Which in turn raises the question whether it
>>>>>>>> is indeed Misra (and not just Eclair) which deems initialization a side
>>>>>>>> effect. This is even more so relevant as 13.6 talks of only expressions,
>>>>>>>> yet initializers fall under declarations (in turn involving an expression
>>>>>>>> on the rhs of the equal sign).
>>>>>>>>
>>>>>>>> All the same of course affects patch 2 then, too.
>>>>>>>
>>>>>>> MISRA C leaves the definition of "side effect" to the C Standard.
>>>>>>> E.g., C18 5.1.2.3p2:
>>>>>>>
>>>>>>>      Accessing a volatile object, modifying an object, modifying a file,
>>>>>>>      or calling a function that does any of those operations are all
>>>>>>>      side effects,[omitted irrelevant footnote reference] which are
>>>>>>>      changes in the state of the execution environment.
>>>>>>>
>>>>>>> The MISRA C:2012/2023 Glossary entry for "Persistent side effect"
>>>>>>> indirectly confirms that initialization is always a side effect.
>>>>>>
>>>>>> Hmm, that's interesting: There's indeed an example with an initializer
>>>>>> there. Yet to me the text you quote from the C standard does not say
>>>>>> that initialization is a side effect - it would be "modifying an
>>>>>> object" aiui, yet ahead of initialization being complete the object
>>>>>> doesn't "exist" imo, and hence can be "modified" only afterwards.
>>>>>
>>>>> I feel it's becoming a bit too philosophical. Since there's some room
>>>>> for interpretation and only two violations left to address, I believe
>>>>> it's best to stick with the stricter interpretation of the definition.
>>>>> Therefore, I'd proceed with this series in its current form.
>>>>
>>>> Proceeding with the series in its current form may be okay (as you say,
>>>> you view the changes as readability improvements anyway), but imo the
>>>> interpretation needs settling on no matter what. In fact even for these
>>>> two patches it may affect what their descriptions ought to say (would
>>>> be nice imo to avoid permanently recording potentially misleading
>>>> information by committing as is). And of course clarity would help
>>>> dealing with future instances that might appear. I take it you realize
>>>> that if someone had submitted a patch adding code similar to the
>>>> original forms of what's being altered here, it would be relatively
>>>> unlikely for a reviewer to spot the issue. IOW here we're making
>>>> ourselves heavily dependent upon Eclair spotting (supposed) issues,
>>>> adding extra work and delays for such changes to go in.
>>>
>>> You can do two things to obtain a second opinion:
>>>
>>> 1) Use the MISRA forum (here is the link to the forum
>>>      section devoted to the side-effect rules of MISRA C:2012
>>>      and MISRA C:2023 (https://forum.misra.org.uk/forumdisplay.php?fid=168).
>>>      The MISRA C Working Group will, in due course, provide
>>>      you with an official answer to your questions about what,
>>>      for the interpretation of Rule 13.6, has to be considered
>>>      a side effect.
>>>
>>> 2) Reach out to your ISO National Body and try to obtain
>>>      an official answer from ISO/IEC JTC1/SC22/WG14 (the
>>>      international standardization working group for the
>>>      programming language C) to your questions about what the
>>>      C Standard considers to be side effects.
>>
>> I took the latter route, and to my (positive) surprise I got back an answer
>> the same day. There was a request for someone to confirm, but so far I didn't
>> see further replies. Since this is a German institution I raised the question
>> in German and got back an answer in German (attached); I've tried my best to
>> translate this without falsifying anything, but I've omitted non-technical
>> parts:
>>
>> "Initialization of an object is never a side effect of the initialization
>> by itself. Of course expressions used for initialization can themselves have
>> side effects on other objects.
>>
>> @Andreas: Do you agree? C after all has a far simpler object model than C++.
>> The (potential) change in object representation (i.e. the bytes underlying
>> the object) is not a side effect of object initialization, but its primary
>> purpose."
>>
>> Further for Misra she added a reference to a Swiss person, but I think with
>> Bugseng we have sufficient expertise there.
> 
> Unfortunately, the (translation of the) answer you received adds
> confusion to previous confusion: who answered has highlighted the
> "side" part of the term, which is indeed relevant in computer science,
> but not for the C standard.

I can't see any highlighting in the original reply I received.

>  To the point that the same argument could
> be used to deny that ++i has a side effect because the increment is
> the "primary" effect...

Well, if it's just "++i;" there's no side effect, just a primary one. In
"n = ++i + j--;" there are side effects (the increment and decrement).

> Part of the confusion is maybe in the the following paragraph Jan
> wrote earlier:
> 
>  > Hmm, that's interesting: There's indeed an example with an initializer
>  > there. Yet to me the text you quote from the C standard does not say
>  > that initialization is a side effect - it would be "modifying an
>  > object" aiui, yet ahead of initialization being complete the object
>  > doesn't "exist" imo, and hence can be "modified" only afterwards.
> 
> In C, it is not true that the object does not exist ahead of
> initialization.

I quoted "exist" for that reason. Of course the object's lifetime starts
with its declaration. It just has indeterminate value at that point.

>  Try the following:
> 
> extern int f(int* p);
> 
> int main() {
>    int i = f(&i);
> }

Which to me falls under "Of course expressions used for initialization
can themselves have side effects on other objects." Just that "other"
isn't quite right here.

Jan

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

[Stefano Stabellini]

On Mon, 30 Sep 2024, 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 initialization (even of a local variable)
> a side effect, the chain of expansions mentioned above violates
> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
> contain any expression which has potential side effect).
> 
> Refactor the code to address the rule violation.
> 
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

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

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Wed, Oct 02, 2024 at 05:36:47PM -0700, Stefano Stabellini wrote:
> On Mon, 30 Sep 2024, 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 initialization (even of a local variable)
> > a side effect, the chain of expansions mentioned above violates
> > MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
> > contain any expression which has potential side effect).
> > 
> > Refactor the code to address the rule violation.
> > 
> > Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[XEN PATCH v2 2/3] xen/gnttab: address a violation of MISRA C Rule 13.6

[Federico Serafini]

guest_handle_ok()'s expansion contains a sizeof() involving its
first argument guest_handle_cast().
The expansion of the latter, in turn, contains a variable
initialization.

Since MISRA considers the initialization (even of a local variable)
a side effect, the chain of expansions mentioned above violates
MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
contain any expression which has potential side effect).

Refactor the code to address the rule violation.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
Changes in v2:
- better description;
- preserved original indentation.
---
 xen/common/compat/grant_table.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index 5ad0debf96..bbb717bf64 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -78,12 +78,15 @@ int compat_grant_table_op(
         cmd_op = cmd;
     switch ( cmd_op )
     {
-#define CASE(name) \
-    case GNTTABOP_##name: \
-        if ( unlikely(!guest_handle_okay(guest_handle_cast(uop, \
-                                                           gnttab_##name##_compat_t), \
-                                         count)) ) \
-            rc = -EFAULT; \
+#define CASE(name)                                                  \
+    case GNTTABOP_ ## name:                                         \
+    {                                                               \
+        XEN_GUEST_HANDLE_PARAM(gnttab_ ## name ## _compat_t) h =    \
+            guest_handle_cast(uop, gnttab_ ## name ## _compat_t);   \
+                                                                    \
+        if ( unlikely(!guest_handle_okay(h, count)) )               \
+            rc = -EFAULT;                                           \
+    }                                                               \
         break
 
 #ifndef CHECK_gnttab_map_grant_ref
-- 
2.43.0

Re: [XEN PATCH v2 2/3] xen/gnttab: address a violation of MISRA C Rule 13.6

[Stefano Stabellini]

On Mon, 30 Sep 2024, Federico Serafini wrote:
> guest_handle_ok()'s expansion contains a sizeof() involving its
> first argument guest_handle_cast().
> The expansion of the latter, in turn, contains a variable
> initialization.
> 
> Since MISRA considers the initialization (even of a local variable)
> a side effect, the chain of expansions mentioned above violates
> MISRA C:2012 Rule 13.6 (The operand of the `sizeof' operator shall not
> contain any expression which has potential side effect).
> 
> Refactor the code to address the rule violation.
> 
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>

There is a pending interesting comment from Jan on patch #1 that affects
this patch too, but I think this patch is good even just as a
readability improvement so I'll review it as is


> ---
> Changes in v2:
> - better description;
> - preserved original indentation.
> ---
>  xen/common/compat/grant_table.c | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
> index 5ad0debf96..bbb717bf64 100644
> --- a/xen/common/compat/grant_table.c
> +++ b/xen/common/compat/grant_table.c
> @@ -78,12 +78,15 @@ int compat_grant_table_op(
>          cmd_op = cmd;
>      switch ( cmd_op )
>      {
> -#define CASE(name) \
> -    case GNTTABOP_##name: \
> -        if ( unlikely(!guest_handle_okay(guest_handle_cast(uop, \
> -                                                           gnttab_##name##_compat_t), \
> -                                         count)) ) \
> -            rc = -EFAULT; \
> +#define CASE(name)                                                  \
> +    case GNTTABOP_ ## name:                                         \
> +    {                                                               \
> +        XEN_GUEST_HANDLE_PARAM(gnttab_ ## name ## _compat_t) h =    \
> +            guest_handle_cast(uop, gnttab_ ## name ## _compat_t);   \
> +                                                                    \
> +        if ( unlikely(!guest_handle_okay(h, count)) )               \
> +            rc = -EFAULT;                                           \
> +    }                                                               \
>          break

We would typically put the break within the case { }

Other than that, I think this. With that change:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>



>  #ifndef CHECK_gnttab_map_grant_ref
> -- 
> 2.43.0
> 

Re: [XEN PATCH v2 2/3] xen/gnttab: address a violation of MISRA C Rule 13.6

[Jan Beulich]

On 01.10.2024 00:53, Stefano Stabellini wrote:
> On Mon, 30 Sep 2024, Federico Serafini wrote:
>> --- a/xen/common/compat/grant_table.c
>> +++ b/xen/common/compat/grant_table.c
>> @@ -78,12 +78,15 @@ int compat_grant_table_op(
>>          cmd_op = cmd;
>>      switch ( cmd_op )
>>      {
>> -#define CASE(name) \
>> -    case GNTTABOP_##name: \
>> -        if ( unlikely(!guest_handle_okay(guest_handle_cast(uop, \
>> -                                                           gnttab_##name##_compat_t), \
>> -                                         count)) ) \
>> -            rc = -EFAULT; \
>> +#define CASE(name)                                                  \
>> +    case GNTTABOP_ ## name:                                         \
>> +    {                                                               \
>> +        XEN_GUEST_HANDLE_PARAM(gnttab_ ## name ## _compat_t) h =    \
>> +            guest_handle_cast(uop, gnttab_ ## name ## _compat_t);   \
>> +                                                                    \
>> +        if ( unlikely(!guest_handle_okay(h, count)) )               \
>> +            rc = -EFAULT;                                           \
>> +    }                                                               \
>>          break
> 
> We would typically put the break within the case { }

That won't work very well with the break not having a semicolon, for the
semicolon to actually be used when invoking the macro. Moving the break
(while adding a semicolon there) as you suggest would then mean the use
site semicolon to end up being an unreachable statement.

Jan

Re: [XEN PATCH v2 2/3] xen/gnttab: address a violation of MISRA C Rule 13.6

[Stefano Stabellini]

On Tue, 1 Oct 2024, Jan Beulich wrote:
> On 01.10.2024 00:53, Stefano Stabellini wrote:
> > On Mon, 30 Sep 2024, Federico Serafini wrote:
> >> --- a/xen/common/compat/grant_table.c
> >> +++ b/xen/common/compat/grant_table.c
> >> @@ -78,12 +78,15 @@ int compat_grant_table_op(
> >>          cmd_op = cmd;
> >>      switch ( cmd_op )
> >>      {
> >> -#define CASE(name) \
> >> -    case GNTTABOP_##name: \
> >> -        if ( unlikely(!guest_handle_okay(guest_handle_cast(uop, \
> >> -                                                           gnttab_##name##_compat_t), \
> >> -                                         count)) ) \
> >> -            rc = -EFAULT; \
> >> +#define CASE(name)                                                  \
> >> +    case GNTTABOP_ ## name:                                         \
> >> +    {                                                               \
> >> +        XEN_GUEST_HANDLE_PARAM(gnttab_ ## name ## _compat_t) h =    \
> >> +            guest_handle_cast(uop, gnttab_ ## name ## _compat_t);   \
> >> +                                                                    \
> >> +        if ( unlikely(!guest_handle_okay(h, count)) )               \
> >> +            rc = -EFAULT;                                           \
> >> +    }                                                               \
> >>          break
> > 
> > We would typically put the break within the case { }
> 
> That won't work very well with the break not having a semicolon, for the
> semicolon to actually be used when invoking the macro. Moving the break
> (while adding a semicolon there) as you suggest would then mean the use
> site semicolon to end up being an unreachable statement.

I didn't think of the extra semicolon posing a problem. In that case, it
is better as it is in this patch

[XEN PATCH v2 3/3] automation/eclair: tag Rule 13.6 as clean

[Federico Serafini]

Update ECLAIR configuration to consider Rule 13.6 as clean:
new violations of this rule will cause a failure of the CI pipeline.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
 automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index b8448938e6..76032b1fe1 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -60,6 +60,7 @@ MC3R1.R11.6||
 MC3R1.R11.7||
 MC3R1.R11.9||
 MC3R1.R12.5||
+MC3R1.R13.6||
 MC3R1.R14.1||
 MC3R1.R14.3||
 MC3R1.R14.4||
-- 
2.43.0

Re: [XEN PATCH v2 3/3] automation/eclair: tag Rule 13.6 as clean

[Stefano Stabellini]

On Mon, 30 Sep 2024, Federico Serafini wrote:
> Update ECLAIR configuration to consider Rule 13.6 as clean:
> new violations of this rule will cause a failure of the CI pipeline.
> 
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index b8448938e6..76032b1fe1 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -60,6 +60,7 @@ MC3R1.R11.6||
>  MC3R1.R11.7||
>  MC3R1.R11.9||
>  MC3R1.R12.5||
> +MC3R1.R13.6||
>  MC3R1.R14.1||
>  MC3R1.R14.3||
>  MC3R1.R14.4||
> -- 
> 2.43.0
>