On 01.08.2019 14:16, Viktor Mitin wrote:
> I expected you to have some arguments why it cannot be fixed in the
> diff or other tools.
I don't follow: How does it matter here whether I have arguments towards
(not) fixing diff etc? That's their maintainers' arguments, if any, not
mine. All I know (from the last time we've been discussing this) is that
even up-to-date diff (at that time at least, i.e. a few months back)
still behaved that way. Which means if it was fixed today, it would
still be a few years out at least until we could assume old diff isn't
in use anymore.
> The examples I meant are any real patches code examples to be used for
> this investigation.
You can easily observe the anomaly yourself. You could also go hunt for
the previous discussion. To me, this discussion as a whole has already
taken far more time than it would take to "manually" comment on _many_
patches violating style. I'm fine to provide input here, but the
overhead time- wise needs to remain reasonable. And as much as I
appreciate you to have taken on this task, I think part of the decision
to do so should have been to familiarize yourself with prior discussions
on the subject.
Anyway - here is your example:
--- unstable.orig/xen/common/grant_table.c
+++ unstable/xen/common/grant_table.c
@@ -1573,6 +1573,7 @@ fault:
for ( i = 0; i < partial_done; i++ )
unmap_common_complete(&common[i]);
+ (void)0;
return -EFAULT;
}
Without the function name the code addition is ambiguous; line numbers
can't always be relied upon, and code review often can be done without
actually opening the file in question and looking at the patched code
location.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
