From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Tue, 03 Apr 2012 06:28:46 +1000 Subject: [U-Boot] [PATCH] Prevent malloc with size 0 In-Reply-To: References: <4CC006B1.8000905@intracomdefense.com> <201204012312.35363.vapier@gentoo.org> <201204020536.23204.marek.vasut@gmail.com> Message-ID: <4F7A0BFE.50905@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 On 04/02/2012 05:40 PM, Joakim Tjernlund wrote: > Hi Grame > > Graeme Russ wrote on 2012/04/02 09:17:44: >> >> Hi Joakim, >> On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" wrote: >>> >>>> >>>> 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 >>> >>> Then u-boot will be incompatible with both glibc and the linux kernel, it seems >> Forget aboug other implementations... >> What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account > > Well, u-boot borrows code from both kernel and user space so it would make sense if > malloc(0) behaved the same. Especially for kernel code which tend to depend on the > kernels impl.(just look at Scotts example) > >>> to me that any modern impl. of malloc(0) will return a non NULL ptr. >>> >>> It does need to be slower, just return ~0 instead, the kernel does something similar: >>> if (!size) >>> return ZERO_SIZE_PTR; >> That could work, but technically I don't think it complies as it is not a pointer to allocated memory... > > It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on. As per the spec: The malloc function returns either a null pointer or a pointer to the allocated space. The amount of storage allocated by a successful call to the calloc, malloc, or realloc function when 0 bytes was requested (7.22.3). The way I read that, if NULL is not returned, then what is returned is a pointer to allocated space. If malloc(0) is called, the amount of space allocated is not determined by the spec Regards, Graeme