Marek Vasut marek.vasut@gmail.com wrote on 2012/04/02 17:23:03:
Dear Joakim Tjernlund,
Marek Vasut marek.vasut@gmail.com wrote on 2012/04/02 16:42:30:
Dear Joakim Tjernlund,
Marek Vasut marek.vasut@gmail.com wrote on 2012/04/02 16:05:13:
Dear Joakim Tjernlund,
Hi Grame
Graeme Russ graeme.russ@gmail.com wrote on 2012/04/02 09:17:44: > Hi Joakim, > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" > joakim.tjernlund@transmode.se
wrote:
> > > Hi Marek, > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut > > > marek.vasut@gmail.com
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?
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.
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