From owner-freebsd-hackers  Wed Apr 12 08:20:21 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id IAA15699
          for hackers-outgoing; Wed, 12 Apr 1995 08:20:21 -0700
Received: from p5.spnet.com (spnet.com [204.156.130.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA15693
          for <hackers@freebsd.org>; Wed, 12 Apr 1995 08:20:19 -0700
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 IAA07172; Wed, 12 Apr 1995 08:20:16 -0700
Message-Id: <199504121520.IAA07172@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
Date: Wed, 12 Apr 1995 08:20:16 -0700
From: Ed Hudson <elh@p5.spnet.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk


howdy.

	while you folks are reconsidering malloc...

	a while ago i encountered an 'application almost bug' wherein
	sbrk(1) returns (old_mem+1).  Some other unix's
	(e.g., SunOS) return a double word aliged value.
	
	since SunOS is perhaps one of the largest porting sources
	that FreeBSD can get applications from, i think that obscure
	bugs, as well as obscure performance anomalies could be
	prevented if FreeBSD were to adopt this behavior.

	i'd like to ask you folks to reconsider adopting the SunOS
	sbrk() behavior...  in the interests of maximizing the acceptance of
	FreeBSD by minimizing the porting hassles, as well as performance
	problems for random applications that do their own sbrk'ing
	(and not malloc-ing).  and yes, there probably aren't many applications
	that do this, but i think the current sbrk() behavior is a tiny
	time bomb.

	thanks,

		-elh