brk(2) vs. end(3) - (nf)

PAD Powell [Admin] padpowell at wateng.UUCP
Wed Nov 30 02:12:56 AEST 1983


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)???



More information about the Comp.bugs.4bsd.ucb-fixes mailing list