>Number:         7937
>Category:       lib
>Synopsis:       malloc/sbrk interaction poorly documented
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul  6 11:20:00 1999
>Last-Modified:
>Originator:     Perry E. Metzger
>Organization:
Perry Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you."
>Release:        NetBSD-current
>Environment:
	
System: NetBSD jekyll.piermont.com 1.4 NetBSD 1.4 (JEKYLL) #0: Mon May 3 09:58:15 EDT 1999 perry@jekyll.piermont.com:/usr/src/sys/arch/i386/compile/JEKYLL i386


>Description:

malloc and sbrk: are they friends or enemies? Who knows?

According to XPG, using both in the same program is not guaranteed to
be safe. Some say that "we've always allowed that". Some say "some of
our platforms have always caused programs to do bad things if you did
that". It is all unclear.

I've recently upgraded the brk/sbrk man page to indicate mixing malloc 
and sbrk is non-portable (in accordance with XPG). However, we have to 
document what _OUR_ API guarantees. Are you allowed to mix them, or
not? If so, we should document that explicitly on the *alloc and
brk/sbrk man pages. If not, we should explicitly document *that*. We
should note in either case that the behavior is undefined in a
portable context.

>How-To-Repeat:

man sbrk
man malloc

scratch head

>Fix:
Make a decision, document it and stick with it. My understanding is
that the new phk malloc() may force the issue.
>Audit-Trail:
>Unformatted: