[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 #6 from Sebastian Huber <sebastian.huber at embedded-brains.de> 2011-01-25 07:04:56 CST ---
(In reply to comment #5)
> (In reply to comment #4)
> > The non-NULL return is more common.
> 
> I regret, but you leave me no other choice but to become more explicit.
> 
> a) malloc(0) is non-portable code and needs special treatment on the caller
> side. I.e. It's unsafe and nonportable (== broken code) to call malloc(size) if
> size can be < 1.

Yes, it is non-portable.  What do you mean with unsafe?

> 
> 
> 
> b) your sentence above is wrong.

It is not only my sentence.  Please have a look at

http://www.gnu.org/software/hello/manual/autoconf/Function-Portability.html

> 
> malloc(0) returning 0 is the tradional unix behavior and is much older than
> Linux and POSIX. May be it's thanks to your age and due to your lack of
> experience with other OSes but Linux, you're not aware about this.

It is interesting that you assume that I lack experience with other operating
systems than Linux.  Who do you know?

In fact FreeBSD returns non-NULL.  I bumped into that problem while using some
FreeBSD kernel code.  In particular the device_get_children() function.

> 
> > RTEMS needs a special case to force the
> > NULL return of malloc(0). 
> So what? What is the problem you are trying to resolve?

I try make it as easy as possible to use code that works on FreeBSD or Linux.

> 
> > A _Workspace_Allocate(0) will return non-NULL for
> > example.
> So what? Implementation detail.
> 
> >  The C standard declares two valid implementation behaviors.  I don't
> > see why RTEMS should choose one that is less common and in addition to that
> > needs a special case to enforce it.
> 
> Pardon ... cf. above.

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.

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