Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wateng.UUCP
Path: utzoo!watmath!watdaisy!wateng!padpowell
From: padpowell@wateng.UUCP (PAD Powell [Admin])
Newsgroups: net.bugs.4bsd
Subject: Re: brk(2) vs. end(3) - (nf)
Message-ID: <556@wateng.UUCP>
Date: Tue, 29-Nov-83 11:12:56 EST
Article-I.D.: wateng.556
Posted: Tue Nov 29 11:12:56 1983
Date-Received: Wed, 30-Nov-83 04:41:45 EST
References: <2227@rabbit.UUCP>
Organization: U of Waterloo, Ontario
Lines: 47

WARNING:  I have just read the documentation for sbrk, and have come to
the conclusion that calling sbrk(0) will cause at least some memory to be
allocated, as the docuemtation states that this will be done.
I have just experimented, and SUNAVBITCH!  it doesn't seem to do this on 4.1,
at least here at Waterloo, but the behaviours on 4.1a/Version 7/System 3/ 
may be slightly different.
Try the following little gem to see what you have:
#define BLKSIZE 1024
main()
    {
	static char *new_base, *old_base, *new_top, *old_top;
	char *sbrk();
	int i;
	for(i=0; i<100; ++i ){
		old_base = new_base;
		old_top = new_top;
		new_base = sbrk(0);
		new_top = sbrk(BLKSIZE);  /* read sbrk(2) about rounding up */
		if( (int)new_base == -1 || (int)new_top == -1 ){
			printf( "THUD! limit reached\n" );
			return;
		}
	printf( "old_base %ld, old_top %ld, new_base %ld, new_top %ld\n",
			(long int)old_base,(long int)old_top,
			(long int)new_base,(long int)new_top);
		if( old_top && old_top != new_base ){
			printf( "Gotcha! funny alignment snuck in\n" );
			return;
		}
		if( new_top != new_base ){
			printf( "Gotcha! allocated something for sbrk(0)\n" );
			return;
		}
		new_top += BLKSIZE;
	}
    }

I must admit that this area seems to be one of the biggest botches
in the kernel design.  Break function, and C break?  Sigh.

Patrick Powell

P.S.- Why don't we simply make this a new defintion of sbrk, modify the
man pages,  and FORCE implementors to return the top address for
sbrk(0)???