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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.