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

[Julien Grall <julien.grall@xxxxxxx>]

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.
> > 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.
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,
--
Julien Grall

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