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

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

[George Dunlap]

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

Hi all,

Sorry for sending this out so late; my calendar was screwed up.  Due to it being a public holiday in the UK, I propose moving the monthly community call to NEXT THURSDAY, 9 June, same time.

The proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/URCDNNBOVKsEK2grXf2l954a/ and you can edit to add items.  Alternatively, you can reply to this mail directly.

Agenda items appreciated a few days before the call: please put your name besides items if you edit the document.

Note the following administrative conventions for the call:
* Unless, agreed in the pervious meeting otherwise, the call is on the 1st Thursday of each month at 1600 British Time (either GMT or BST)
* I usually send out a meeting reminder a few days before with a provisional agenda

* To allow time to switch between meetings, we'll plan on starting the agenda at 16:05 sharp.  Aim to join by 16:03 if possible to allocate time to sort out technical difficulties &c

* If you want to be CC'ed please add or remove yourself from the sign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/

Best Regards
George



== Dial-in Information ==
## Meeting time
15:00 - 16:00 UTC
Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=06&day=9&hour=15&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179


## Dial in details
Web: https://meet.jit.si/XenProjectCommunityCall

Dial-in info and pin can be found here:

https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stefano Stabellini]

Hi all,

I would like to suggest to have the MISRA C meeting just before the
community call (7AM California time). If it is difficult for any of the
must-have attendees, then I would like to ask to reserve 30 minutes of
the community call to make progress on MISRA.

Cheers,

Stefano


On Wed, 1 Jun 2022, George Dunlap wrote:
> Hi all,
> 
> Sorry for sending this out so late; my calendar was screwed up.  Due to it being a public holiday in the UK, I propose moving the monthly community call to NEXT THURSDAY, 9 June, same time.
> 
> The proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/URCDNNBOVKsEK2grXf2l954a/ and you can edit to add items.  Alternatively, you can reply to this mail directly.
> 
> Agenda items appreciated a few days before the call: please put your name besides items if you edit the document.
> 
> Note the following administrative conventions for the call:
> * Unless, agreed in the pervious meeting otherwise, the call is on the 1st Thursday of each month at 1600 British Time (either GMT or BST)
> * I usually send out a meeting reminder a few days before with a provisional agenda
> 
> * To allow time to switch between meetings, we'll plan on starting the agenda at 16:05 sharp.  Aim to join by 16:03 if possible to allocate time to sort out technical difficulties &c
> 
> * If you want to be CC'ed please add or remove yourself from the sign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/
> 
> Best Regards
> George
> 
> 
> 
> == Dial-in Information ==
> ## Meeting time
> 15:00 - 16:00 UTC
> Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=06&day=9&hour=15&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179
> 
> 
> ## Dial in details
> Web: https://meet.jit.si/XenProjectCommunityCall
> 
> Dial-in info and pin can be found here:
> 
> https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall
> 

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

[Stefano Stabellini]

Reducing CC and adding fusa-sig

Actually Jun 9 at 8AM California / 4PM UK doesn't work for some of you,
so it is either:
1) Jun 9 at 7AM California / 3PM UK
2) Jun 14 at 8AM California / 4PM UK

My preference is the first option because it is sooner but let me know
if it doesn't work and we'll try the second option.



On Wed, 1 Jun 2022, Stefano Stabellini wrote:
> Hi all,
> 
> I would like to suggest to have the MISRA C meeting just before the
> community call (7AM California time). If it is difficult for any of the
> must-have attendees, then I would like to ask to reserve 30 minutes of
> the community call to make progress on MISRA.
> 
> Cheers,
> 
> Stefano
> 
> 
> On Wed, 1 Jun 2022, George Dunlap wrote:
> > Hi all,
> > 
> > Sorry for sending this out so late; my calendar was screwed up.  Due to it being a public holiday in the UK, I propose moving the monthly community call to NEXT THURSDAY, 9 June, same time.
> > 
> > The proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/URCDNNBOVKsEK2grXf2l954a/ and you can edit to add items.  Alternatively, you can reply to this mail directly.
> > 
> > Agenda items appreciated a few days before the call: please put your name besides items if you edit the document.
> > 
> > Note the following administrative conventions for the call:
> > * Unless, agreed in the pervious meeting otherwise, the call is on the 1st Thursday of each month at 1600 British Time (either GMT or BST)
> > * I usually send out a meeting reminder a few days before with a provisional agenda
> > 
> > * To allow time to switch between meetings, we'll plan on starting the agenda at 16:05 sharp.  Aim to join by 16:03 if possible to allocate time to sort out technical difficulties &c
> > 
> > * If you want to be CC'ed please add or remove yourself from the sign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/
> > 
> > Best Regards
> > George
> > 
> > 
> > 
> > == Dial-in Information ==
> > ## Meeting time
> > 15:00 - 16:00 UTC
> > Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=06&day=9&hour=15&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179
> > 
> > 
> > ## Dial in details
> > Web: https://meet.jit.si/XenProjectCommunityCall
> > 
> > Dial-in info and pin can be found here:
> > 
> > https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall
> > 
> 

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

[Jan Beulich]

On 01.06.2022 22:27, Stefano Stabellini wrote:
> Reducing CC and adding fusa-sig
> 
> Actually Jun 9 at 8AM California / 4PM UK doesn't work for some of you,
> so it is either:
> 1) Jun 9 at 7AM California / 3PM UK
> 2) Jun 14 at 8AM California / 4PM UK
> 
> My preference is the first option because it is sooner but let me know
> if it doesn't work and we'll try the second option.

I don't think I was aware that another call is needed. Was that said
somewhere earlier where I did miss it? In any event, either option
looks to be okay here.

Jan

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

[Stefano Stabellini]

On Thu, 2 Jun 2022, Jan Beulich wrote:
> On 01.06.2022 22:27, Stefano Stabellini wrote:
> > Reducing CC and adding fusa-sig
> > 
> > Actually Jun 9 at 8AM California / 4PM UK doesn't work for some of you,
> > so it is either:
> > 1) Jun 9 at 7AM California / 3PM UK
> > 2) Jun 14 at 8AM California / 4PM UK
> > 
> > My preference is the first option because it is sooner but let me know
> > if it doesn't work and we'll try the second option.
> 
> I don't think I was aware that another call is needed. Was that said
> somewhere earlier where I did miss it? In any event, either option
> looks to be okay here.

I sent out the meeting invite for Jun 9 at 7AM California / 3PM UK.

Just a reminder to fill in the remaining "yellow" rules of the
spreadsheet in advance of the meeting.


There are couple of interesting questions on the remaining rules, which
I tried to shed some light on.



# 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 variables are "possibly
uninitialized". We should ask Roberto about them, I don't think they are
actual errors? More like extra warnings?


# Rule 9.3 "Arrays shall not be partially initialized"

Andrew was pointing out that "we use implicit 0's all over the place".

That is true but as far as I can tell that is permitted. There is a
couple of exceptions to the rules:

- { 0 } is allowed

- sparse initialization using designated initializers is allowed
  e.g. char ar[3] = { [2] = 'c' }

So I think we are fine there.


# Rule 9.4 "An element of an object shall not be initialized more than once"

Andrew was noting that "There's one pattern using range syntax to set a
default where this rule would be violated, but the code is far cleaner
to read."

Range initializers is a GCC extension not part of the C standard. It is
not considered by the MISRA rule. The MISRA rule seems focused on
preveting accidental double-initializations (by copy/pasting errors for
instance) which is fair.

So I think we should be OK here and we need to clarify our usage of
range initializers. What we do or don't do with range initializer should
be a separate discussion I think.

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

[Jan Beulich]

On 07.06.2022 04:17, Stefano Stabellini wrote:
> # Rule 9.4 "An element of an object shall not be initialized more than once"
> 
> Andrew was noting that "There's one pattern using range syntax to set a
> default where this rule would be violated, but the code is far cleaner
> to read."

I'm actually not sure we have such uses, as I seem to vaguely recall clang
warning about them. Off the top of your head, do you know of an instance,
Andrew?

Jan

> Range initializers is a GCC extension not part of the C standard. It is
> not considered by the MISRA rule. The MISRA rule seems focused on
> preveting accidental double-initializations (by copy/pasting errors for
> instance) which is fair.
> 
> So I think we should be OK here and we need to clarify our usage of
> range initializers. What we do or don't do with range initializer should
> be a separate discussion I think.
> 

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

[Stefano Stabellini]

Hi all,

Just a quick note to have another look at the spreadsheet before the
meeting tomorrow. I cleared the old rules we have already discussed
leaving only the ones to discuss next.


A few rules are similar to the already accepted Rule 5.1 with our agreed
40 characters limit for identifiers:
- Rule 5.2
- Rule 5.4


A couple of rules are about comparisons/operations between pointers to
different objects:
- Rule 18.1
- Rule 18.2
- Rule 18.3
In my opinion these rules are good in the general case. Things like _end
- _start and other "fake objects" should be deviations.


A few rules weren't clear:
- Rule 13.1, the example link was wrong, I updated it
- Rule 9.3, { 0 } is allowed by the rule and also { [2] = 1 } is allowed
- Rule 9.4, range initializers are not considered by the rule because
            they are a GNU extension


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.


Looking forward to our discussion tomorrow!

Cheers,

Stefano

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

[Jan Beulich]

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/efi/ebmalloc.c to check,
and it says "possibly". That's because evaluation of function call
arguments involves the calling of (in this case two) further
functions. If those functions had side effects (which apparently the
tool can't figure), there would indeed be a problem.

The (Arm based) count of almost 10k violations is clearly a concern.
I don't consider it even remotely reasonable to add 10k comments, no
matter how brief, to cover all the false positives.

Jan

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

[Roberto Bagnara]

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 variables are "possibly
 > uninitialized". We should ask Roberto about them, I don't think they are
 > actual errors? More like extra warnings?

No, -Wuninitialized is not reliable, as it has plenty of (well known)
false negatives.  This is typical of compilers, for which the generation
of warnings is only a secondary objective.  I wrote about that here:

   https://www.bugseng.com/blog/compiler-warnings-use-them-dont-trust-them

On the specifics:

$ cat p.c
int foo (int b)
{
     int a;

     if (b)
     {
         a = 1;
     }

     return a;
}

$ gcc -c -W -Wall -Wmaybe-uninitialized -O3 p.c
$ gcc -c -W -Wall -Wuninitialized -O3 p.c
$

Note that the example is less contrived than you might think.
See, JF Bastien's talk at 2019 LLVM Developers' Meeting:

   https://www.youtube.com/watch?v=I-XUHPimq3o

More generally, you can only embrace MISRA if you agree on
its preventive nature, which is radically different from
the "bug finding" approach.  The point is rather simple:

1) static analysis alone cannot guarantee correctness;
2) peer review is unavoidable;
3) testing is unavoidable.

In order to effectively conduct a peer review, you cannot
afford being distracted every minute by the thought
"is this initialized?  where is it initialized?  with which
value is it initialized?"
In a MISRA setting, you want that the answer to such questions
is immediately clear to anyone.
In contrast, if you embrace bug finding (that is, checkers with
false negatives like the ones implemented by compilers),
you will miss instances that you may miss also with testing
(testing a program with UB does not give reliable results);
and you will likely miss them with peer review, unless you
can spend a lot of time and resources in the activity.

The checker implemented by ECLAIR for Rule 9.1 embodies this
principle: if it says "violation", then it is a definite
violation;  if it says "caution", then maybe there is no
UB, but a human will have to spend more than 30 seconds
in order to convince herself that there is no UB.

I understand this may sound frustrating to virtuoso programmers,
and there are many of them in the open source world.
But the truth is that virtuosity in programming is not a good
thing for safety-related development.   For safety you want
code that is simple and straightforward to reason about.
Kind regards,

    Roberto

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

[Roberto Bagnara]

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/efi/ebmalloc.c to check,
> and it says "possibly". That's because evaluation of function call
> arguments involves the calling of (in this case two) further
> functions. If those functions had side effects (which apparently the
> tool can't figure), there would indeed be a problem.
> 
> The (Arm based) count of almost 10k violations is clearly a concern.
> I don't consider it even remotely reasonable to add 10k comments, no
> matter how brief, to cover all the false positives.

Again, the MISRA approach is a preventive one.
If you have reasons you want to write

    f(g(), h());

then declare g() and h() as pure (or const, if they are const).
E.g.:

#if COMPILER_SUPPORTS_PURE
#define PURE __attribute__((pure))
#else
#define PURE
#endif

int g(void) PURE;
int h(void) PURE;

It's good documentation, it improves compiler diagnostics,
and it satisfies Rule 13.2.
Kind regards,

    Roberto

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

[Jan Beulich]

On 09.06.2022 13:11, Roberto Bagnara wrote:
> 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 variables are "possibly
>  > uninitialized". We should ask Roberto about them, I don't think they are
>  > actual errors? More like extra warnings?
> 
> No, -Wuninitialized is not reliable, as it has plenty of (well known)
> false negatives.  This is typical of compilers, for which the generation
> of warnings is only a secondary objective.  I wrote about that here:
> 
>    https://www.bugseng.com/blog/compiler-warnings-use-them-dont-trust-them
> 
> On the specifics:
> 
> $ cat p.c
> int foo (int b)
> {
>      int a;
> 
>      if (b)
>      {
>          a = 1;
>      }
> 
>      return a;
> }
> 
> $ gcc -c -W -Wall -Wmaybe-uninitialized -O3 p.c
> $ gcc -c -W -Wall -Wuninitialized -O3 p.c
> $
> 
> Note that the example is less contrived than you might think.
> See, JF Bastien's talk at 2019 LLVM Developers' Meeting:
> 
>    https://www.youtube.com/watch?v=I-XUHPimq3o
> 
> More generally, you can only embrace MISRA if you agree on
> its preventive nature, which is radically different from
> the "bug finding" approach.  The point is rather simple:
> 
> 1) static analysis alone cannot guarantee correctness;
> 2) peer review is unavoidable;
> 3) testing is unavoidable.
> 
> In order to effectively conduct a peer review, you cannot
> afford being distracted every minute by the thought
> "is this initialized?  where is it initialized?  with which
> value is it initialized?"
> In a MISRA setting, you want that the answer to such questions
> is immediately clear to anyone.
> In contrast, if you embrace bug finding (that is, checkers with
> false negatives like the ones implemented by compilers),
> you will miss instances that you may miss also with testing
> (testing a program with UB does not give reliable results);
> and you will likely miss them with peer review, unless you
> can spend a lot of time and resources in the activity.
> 
> The checker implemented by ECLAIR for Rule 9.1 embodies this
> principle: if it says "violation", then it is a definite
> violation;  if it says "caution", then maybe there is no
> UB, but a human will have to spend more than 30 seconds
> in order to convince herself that there is no UB.
> 
> I understand this may sound frustrating to virtuoso programmers,
> and there are many of them in the open source world.
> But the truth is that virtuosity in programming is not a good
> thing for safety-related development.   For safety you want
> code that is simple and straightforward to reason about.

I understand what you're saying, yet I'd like to point out that adding
initializers "blindly" may give a false sense of code correctness.
Among other things it takes away the chance for tools to point out
possible issues. Plus some tools warn about stray initializers ...

Jan

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

[Jan Beulich]

On 09.06.2022 13:17, Roberto Bagnara wrote:
> 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/efi/ebmalloc.c to check,
>> and it says "possibly". That's because evaluation of function call
>> arguments involves the calling of (in this case two) further
>> functions. If those functions had side effects (which apparently the
>> tool can't figure), there would indeed be a problem.
>>
>> The (Arm based) count of almost 10k violations is clearly a concern.
>> I don't consider it even remotely reasonable to add 10k comments, no
>> matter how brief, to cover all the false positives.
> 
> Again, the MISRA approach is a preventive one.
> If you have reasons you want to write
> 
>     f(g(), h());
> 
> then declare g() and h() as pure (or const, if they are const).
> E.g.:
> 
> #if COMPILER_SUPPORTS_PURE
> #define PURE __attribute__((pure))
> #else
> #define PURE
> #endif
> 
> int g(void) PURE;
> int h(void) PURE;
> 
> It's good documentation, it improves compiler diagnostics,
> and it satisfies Rule 13.2.

But such attributes first of all should be correct. They wouldn't be
in the case I've looked at (involving two __virt_to_maddr() invocations),
as the underlying va_to_par() isn't pure. Still in the normal case the
sequence of calls made is irrelevant to the overall result.

As to improving compiler diagnostics: It has been my experience that
pure and const are largely ignored when used on inline functions. The
compiler rather looks at the inline-expanded code to judge. (But it has
been a couple of years back that I last checked, so things may have
changed since then.)

Jan

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

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 1757 bytes --]



> On 9 Jun 2022, at 12:24, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 09.06.2022 13:11, Roberto Bagnara wrote:
>> 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 variables are "possibly
>>> uninitialized". We should ask Roberto about them, I don't think they are
>>> actual errors? More like extra warnings?
>> 
>> No, -Wuninitialized is not reliable, as it has plenty of (well known)
>> false negatives. This is typical of compilers, for which the generation
>> of warnings is only a secondary objective. I wrote about that here:
>> 
>> https://www.bugseng.com/blog/compiler-warnings-use-them-dont-trust-them
>> 
>> On the specifics:
>> 
>> $ cat p.c
>> int foo (int b)
>> {
>> int a;
>> 
>> if (b)
>> {
>> a = 1;
>> }
>> 
>> return a;
>> }
>> 

> I understand what you're saying, yet I'd like to point out that adding
> initializers "blindly" may give a false sense of code correctness.
> Among other things it takes away the chance for tools to point out
> possible issues. Plus some tools warn about stray initializers ...

Right — if you always set “int a=0;”, then you’re getting a known value; but if your algorithm relies on it being something specific (and not zero), then it’s not clear the resulting software is actually more reliable.  If you don’t initialise it, there’s at least a chance the compiler will be able to tell you that you made a mistake; if you explicitly initialise it, then it’s all on you.

 -George

[-- Attachment #1.2: Type: text/html, Size: 6814 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]