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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
