Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 2/25/19 3:40 PM, Julien Grall wrote:
> Hi,
>
> On 25/02/2019 13:32, Oleksandr Andrushchenko wrote:
> > On 2/25/19 3:22 PM, Julien Grall wrote:
> > > > Why? If we *first* deal with BUG() and *then* introduce "defaults" 
> > > > patch
> > > > which will use the already fixed code?
> > > This is not how your e-mail came out. It came out as it is fine to 
> > > add "default" with BUG() and then fix it later.
> > Yes, you are correct. But I have an impression that couple of letters 
> > ago
> > I agreed that this *is* an issue and it *does need* a proper fix. And 
> > stated that
> > we might want to fix that separately. So, after that point I thought 
> > the sequence
> > will be:
> > 1. Fix BUG()
> > 2. Use fixed code as a basis for "defaults"
> > Hope we are on the same page now.
> I still don't think 1. has to be fixed first. But I am happy with 
> anything as long as we keep the number of BUG() added limited.
ok, I see
> > > My point is not about sending such code on the mailing list. My 
> > > point is you need to provide as much as possible details in your 
> > > cover letter so we can be more efficient when reviewing. For 
> > > instance, many of us does not have access to MISRA spec because it 
> > > is not free...
> > While I agree that one has to provide as much supporting information 
> > as possible
> > while presenting some work to the community it is that I cannot disclose
> > MISRA rules here. As you said, MISRA spec is not free. And of course 
> > I cannot
> > expect anyone to by it for the reason that someone wants some patch 
> > to be
> > "securely" or blindly reviewed. (BTW, this is the topic that has 
> > already been
> > raised in our team internally and being discussed)
> I understand that MISRA is not free and does not ask you to copy/paste 
> the PDF.
> What I ask is provide enough pointer for us to understand how this 
> fits in Xen code base. For instance, a lot of the MISRA rules have 
> explanation online (see website such as [1] and [2]). Another 
> alternative is to summarize the issues with your own arguments.
Totally agree, I'll try harder next time in finding open sources with rule's
descriptions
> Cheers,
>
> [1] https://rules.sonarsource.com/c/RSPEC-131
> [2] 
> https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
> > > Cheers,
Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel