From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 2 Apr 2012 06:23:50 +0200 Subject: [U-Boot] [PATCH] Prevent malloc with size 0 In-Reply-To: References: <4CC006B1.8000905@intracomdefense.com> <201204020536.23204.marek.vasut@gmail.com> Message-ID: <201204020623.50669.marek.vasut@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Graeme Russ, > Hi Marek, > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut wrote: > > Dear Mike Frysinger, > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote: > >> > b) The code calling malloc(0) is making a perfectly legitimate > >> > assumption > >> > > >> > based on how glibc handles malloc(0) > >> > >> not really. POSIX says malloc(0) is implementation defined (so it may > >> return a unique address, or it may return NULL). no userspace code > >> assuming malloc(0) will return non-NULL is correct. > > > > Which is your implementation-defined ;-) But I have to agree with this > > one. So my vote is for returning NULL. > > Also, no userspace code assuming malloc(0) will return NULL is correct > > Point being, no matter which implementation is chosen, it is up to the > caller to not assume that the choice that was made was, in fact, the > choice that was made. > > I.e. the behaviour of malloc(0) should be able to be changed on a whim > with no side-effects > > So I think I should change my vote to returning NULL for one reason and > one reason only - It is faster during run-time Well, this still might break some code which assumes otherwise ... like you said. And like I said, let's break it because it worked only be a sheer coincidence ;-) > Regards, > > Graeme Best regards, Marek Vasut