From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 26 Sep 2017 15:13:55 -0400 Subject: [U-Boot] [PATCH] test/overlay: Fix various malloc/free leaks In-Reply-To: <0DAF21CFE1B20740AE23D6AF6E54843F1EA7EB5D@IRSMSX101.ger.corp.intel.com> References: <1506444192-3615-1-git-send-email-trini@konsulko.com> <0DAF21CFE1B20740AE23D6AF6E54843F1EA7EB5D@IRSMSX101.ger.corp.intel.com> Message-ID: <20170926191355.GN3112@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Sep 26, 2017 at 06:28:40PM +0000, Langer, Thomas wrote: > Hello Tom, > > I just read some days ago about the kernel Coding-Style: > > > Choose label names which say what the goto does or why the goto exists. An > example of a good name could be ``out_free_buffer:`` if the goto frees ``buffer``. > Avoid using GW-BASIC names like ``err1:`` and ``err2:``, as you would have to > renumber them if you ever add or remove exit paths, and they make correctness > difficult to verify anyway. > > > Does is make sense to follow this for U-Boot also and fix the names of the labels below? > > > > > free(fdt_overlay_stacked_copy); > > +err3: > > free(fdt_overlay_copy); > > +err2: > > free(fdt_base_copy); > > +err1: > > free(uts); > > We have in U-Boot a number of cases of both, and the majority (from a quick read on 'git grep goto' is of the less descriptive case. I can certainly see how descriptive goto labels make more sense in the case of large functions and especially complicated short-cuts. Do you think 'malloc_base_copy_failed', 'malloc_overlay_copy_failed' and 'malloc_stacked_copy_failed' make the code more readable? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: