> 1 file changed, 29 insertions(+), 31 deletions(-) > > So you are asking people to review 60 changed lines to save 2, A bit of object code reduction might become useful also in this case. > that alone should be the point where you stop yourself from > *even* sending this patch. I proposed just another collateral evolution. > Next time before you send a patch please carefully think if the > saving is worth the combination of reviewers time + the risk of > regressions (and keep in mind that both the reviewers time and > the risk of regressions cost increase for more complex changes). Source code transformations were integrated in other software areas according to such a change pattern. > As for this specific discussion, there are certain "design-patterns" > in the kernel, goto style error handling is one of them, the pattern > there ALWAYS is: … > Notice the fall-thoughs those are ALWAYS there, never, ever is > there a goto after a cleanup label. It seems that I present an unusual update suggestion as a software design variant. > Your patches black goto magic completely messes this up You can view the proposal in such a way. > and clearly falls under the CS101 rule: never use goto. There might a target conflict with information from the section “7) Centralized exiting of functions” in the document “coding-style.rst”. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
