From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Subject: Re: mmc: vub300: Use common code in __download_offload_pseudocode() Date: Tue, 31 Oct 2017 10:15:38 +0100 Message-ID: References: <7b418db1-ec35-4c85-5d06-45edde56822c@users.sourceforge.net> <20171030121508.zfnsvpsrt25prhr4@mwanda> <20171031084552.mvvn73pfew4rebsd@mwanda> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20171031084552.mvvn73pfew4rebsd@mwanda> Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org To: Dan Carpenter , Ulf Hansson , "linux-mmc@vger.kernel.org" , linux-usb@vger.kernel.org, kernel-janitors@vger.kernel.org Cc: Tony Olech , LKML List-Id: linux-mmc@vger.kernel.org >>> 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