[Bug 1730] Change malloc(0) behavior to match FreeBSD and Linux

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1730

--- Comment #8 from Sebastian Huber <sebastian.huber at embedded-brains.de> 2011-01-25 07:34:10 CST ---
(In reply to comment #7)
> "It is useless to discuss if implementation A or B is better or whatever. 
> RTEMS should implement the most common one.  This is my point."
> 
> IMHO RTEMS should implement the one most likely to lead to robust code.

If the code depends on the malloc(0) behavior it is not robust code from my
point of view.

> On
> some platforms we can trap NULL dereferences.  I'm not too concerned with a
> minor conditional branch in malloc() - malloc() is always going to be
> heavy-weight due to the nature of the beast.

Yes, this is a point for the current RTEMS approach.

> 
> Can you point to some code I can reference so I can understand the advantage of
> returning a non-NULL non-dereferencable pointer from malloc()?  The only case I
> can make up is code that allocates a pool of pointers, and tests the returned
> pointer for NULL when it's allocated (thus breaking portability), but carefully
> never uses that non-NULL pointer in a way that it is isn't dereferenced.  That
> is dangerous code I want to examine anyway since even if it works today it's
> likely to become broken and trash the heap tomorrow.
> 
> I'm interested to see additional beneficial cases I can't think of.

I don't see any benefits in depending on a particular malloc(0) behavior.  My
problem is that the RTEMS implementation makes it harder to use existing code
that works on FreeBSD and Linux.  In case portability of FreeBSD and Linux
applications is not a RTEMS concern we can use it as it is.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.