From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 2 Apr 2012 18:39:33 +0200 Subject: [U-Boot] [PATCH] Prevent malloc with size 0 In-Reply-To: References: <4CC006B1.8000905@intracomdefense.com> <201204021723.03688.marek.vasut@gmail.com> Message-ID: <201204021839.33172.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 Joakim Tjernlund, > Marek Vasut wrote on 2012/04/02 17:23:03: > > Dear Joakim Tjernlund, > > > > > Marek Vasut wrote on 2012/04/02 16:42:30: > > > > Dear Joakim Tjernlund, > > > > > > > > > Marek Vasut wrote on 2012/04/02 16:05:13: > > > > > > Dear Joakim Tjernlund, > > > > > > > > > > > > > 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. > > > > > > > > > > > > But kernel has something mapped there to trap these pointers I > > > > > > believe. > > > > > > > > > > So? That only means that the kernel has extra protection if someone > > > > > tries to deference such a ptr. You are not required to do that(nice > > > > > to have though) You don have any protection for deferencing NULL > > > > > either I think? > > > > > > > > Can't GCC track it? > > > > > > Track what? NULL ptrs? I don't think so. Possibly when you have a > > > static NULL ptr but not in the general case. > > > > Well of course. > > What did you mean then with "Can't GCC track it?" then? Just a bad joke? Never mind, didn't finish my train of thought. > > > I am getting tired of this discussion now. I am just trying to tell you > > > that no sane impl. of malloc() these days return NULL for malloc(0). > > > > And I got your point. Though for u-boot, this would be the best solution > > actually. Anyone who uses memory allocated by malloc(0) is insane. > > No, you don't get the point. If you did you would not have have made the > "insane" remark. No, relying on malloc(0) returning something sane is messed up. > > > Even > > > though standards allow it they don't consider malloc(0) an error, glibc > > > will not update errno in this case. > > > > There's no errno in uboot I'm aware of ;-) > > Just pointing out that malloc(0) is not an error even if malloc returns > NULL in glibc/standards. malloc(0) represents the empty set, just like 0 > does in math and it is sometimes useful. > > Jocke Best regards, Marek Vasut