From owner-freebsd-hackers  Fri Mar 24 10:27:14 1995
Return-Path: hackers-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA15119 for hackers-outgoing; Fri, 24 Mar 1995 10:27:14 -0800
Received: from p5.spnet.com (elh.com [204.156.130.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA15113 for <hackers@freebsd.org>; Fri, 24 Mar 1995 10:27:12 -0800
Received: from localhost.spnet.com (localhost.spnet.com [127.0.0.1]) by p5.spnet.com (8.6.11/8.6.6) with SMTP id KAA22093; Fri, 24 Mar 1995 10:25:23 GMT
Message-Id: <199503241025.KAA22093@p5.spnet.com>
X-Authentication-Warning: p5.spnet.com: Host localhost.spnet.com didn't use HELO protocol
To: hackers@FreeBSD.org
Cc: elh@p5.spnet.com
Subject: Re: is this reasonable (malloc/sbrk/malloc)? 
In-reply-to: Your message of "Fri, 24 Mar 1995 09:37:25 MST."
             <9503241637.AA09409@cs.weber.edu> 
Date: Fri, 24 Mar 1995 10:25:23 +0000
From: Ed Hudson <elh@p5.spnet.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk


>
>Mixed use of sbrk and malloc is specificially disallowed, even on
>SunOs 4.1.3:
>
>] WARNINGS
>]      Programs combining the brk() and  sbrk()  system  calls  and
>]      malloc()  will not work.  Many library routines use malloc()
>]      internally, so use brk() and sbrk() only when you know  that
>]      malloc() definitely will not be used by any library routine.
>
>
>					Terry Lambert
>					terry@cs.weber.edu

howdy.

	thanks much for the illucidation.

	but am i mistaken, or is the 'WARNINGS' above abscent
	in the man pages for fbsd?

	i ran into this problem porting a large software piece
	(ocean from olt.et.tudelft.nl), which had some C++ code
	calling sbrk, and other routines malloc-ing.  i've always
	believed that intermixing was incorrect, but coudn't see
	any current restrictions stated in fbsd, and had wondered if
	this might be one of the 4.4 improvements...  and even though
	intermixing may be incorrect, the port under SunOS works
	correctly (at least for the included test cases).

	in fbsd, however, subsequent library calls (getcwd()
	via opendir), check to make sure the space returned by
	malloc is aligned, and return NULL (with a misleading
	errno set) if it isn't.

	i've modified the code i'm porting to make references to
	malloc instead of sbrk, but i have some concerns that
	there could be other code that has similar problems
	(NOT NECESSARILY INTERMIXING malloc and sbrk, but just
	expecting SBRK to always have aligned behaviour, which
	fbsd doesn't).  certainly the semantics of sbrk() are different
	in fbsd vs sunos.

	thanks for the information, but i still question:

		1) should fbsd's sbrk returned aligned values,
			ie, emulate SunOS 4.1.x behavior

		2) where's the sbrk/malloc warning in fbsd?

	confused and still a little concerned...

		-elh