>>> What's the advantage of this patch? The new code seems more complicated >>> to me and GCC automatically reuses duplicate constant strings so there >>> is no memory savings. >> >> It looked to me that the error path got a bit cleaner. However, I >> guess it's matter of taste. >> >> If you insist, I can drop it. > > I'm on the kernel-janitors list so I am CC'd on all of Markus's patches. Do you want that I omit this address from the list of recipients? > It's not my code and I'm tired of being the anti-Markus guy Interesting … But I got the impression that this special relationship resulted also in a few useful side effects. > so this patch is fine. Thanks for another bit of acceptance. > Markus has a tool that finds duplicate strings and he uses gotos > to avoid them. Yes. - The script which I am using for the semantic patch language (Coccinelle software) can not only find this implementation detail but also duplicate source code generally to some degree. > I don't think duplicate strings are a problem They can become an issue for further considerations if inappropriate error messages were used for example. There are more statement combinations which can be improved a bit more. > or that it's a good idea to send over a hundred patches using this method. The change acceptance is varying as usual. > But many people have explained that to Markus already I hope that my contributions can improve the affected software in some areas. > and that's not the bigger picture which is about error handling and labels. > What I like are labels that are necessary and self explanatory. It seems that this is a topic where you got strong opinions about. > You're reading along and you're like "what happens at the err" label? Would you accept any further adjustments around questionable jump targets? 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
