From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Date: Tue, 31 Oct 2017 09:15:38 +0000 Subject: Re: mmc: vub300: Use common code in __download_offload_pseudocode() Message-Id: List-Id: References: <7b418db1-ec35-4c85-5d06-45edde56822c@users.sourceforge.net> <20171030121508.zfnsvpsrt25prhr4@mwanda> <20171031084552.mvvn73pfew4rebsd@mwanda> In-Reply-To: <20171031084552.mvvn73pfew4rebsd@mwanda> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: Dan Carpenter , Ulf Hansson , "linux-mmc@vger.kernel.org" , linux-usb@vger.kernel.org, kernel-janitors@vger.kernel.org Cc: Tony Olech , LKML >>> 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. >=20 > 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 =E2=80=A6 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 area= s. > and that's not the bigger picture which is about error handling and label= s. > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html