p500vax:pat (03/22/83)
Calls to sbrk(II) appear to have a delayed effect in our Berkeley VAX 4.1
system.
main()
{
printf( "sbrk(0) = %x\n", sbrk(0) );
printf( "sbrk(1) = %x\n", sbrk(1) );
printf( "sbrk(0) = %x\n", sbrk(0) );
}
produces the following output:
sbrk(0) = 19c4
sbrk(1) = 19c4
sbrk(0) = 19c5mark (03/24/83)
#R:p500vax:-18000:zinfandel:3600002:000:264 zinfandel!mark Mar 23 11:37:00 1983 No delayed effect. From the manual: "... and a pointer to the start of the new area is returned." Note that it doesn't return a pointer to the *END* of the new area, nor does it return the (new) size of the process. Mark Wittenberg ...!decvax!sytek!zehntel!mark
mjs (03/24/83)
What you cite as a bug is simply the way it works. sbrk(n) returns either the address of a block of "n" bytes added to your address space, or it returns -1. In your example, you got the base of 0 bytes added to your space (no growth), then the base of 1 byte added to your space (growth of 1 byte; the result should always be the same number as the previous sbrk(0)!), then the address of the next 0 byte allocation (no growth). Graphically: --------------------- | | | | | | --------------------- ^ ^ 0 sbrk(0) ------------------------- | | | | | | | ------------------------- ^ ^ 0 sbrk(1) ------------------------- | | | | | | | ------------------------- ^ ^ 0 sbrk(0) Martin Shannon, Jr. Phone: (201) 582-3199 Internet: mjs@mhb5b.uucp UUCP: {allegra,rabbit,alice,mhb5b,mhb5c}!mjs USPS: 600 Mountain Avenue Room 5F-120 Murray Hill, NJ 07974
norskog (03/25/83)
#R:p500vax:-18000:fortune:1800001:000:106 fortune!norskog Mar 24 13:58:00 1983 I don't see any delay at all. That's exactly how it should work. Lance Norskog Fortune Systems
johnl (03/26/83)
#R:p500vax:-18000:ima:13500001:000:352
ima!johnl Mar 25 11:46:00 1983
The behavior of sbrk() noted is correct. It returns the old (not the new)
break value so you have the beginning (not the end) of the chunk of
storage allocated.
John Levine, decvax!yale-co!jrl, ucbvax!cbosgd!ima!johnl,
{research|alice|rabbit|amd70}!ima!johnl
PS: This particular fact is clearly documented in the obvious place in
the manual. Bah.crc (03/29/83)
PLEASE STOP SENDING THAT DAMNED REQUEST! ONCE IS ENOUGH!
crc (03/29/83)
THE OTHER MESSAGE WAS IN RESPONCE TO THE MULTIPLE REQUESTS FOR INFO ABOUT MORE THAN N* FILESYSTEMS BEING MOUNTED AT ONCE. It got followuped to the wrong article. sorry.