Path: utzoo!attcan!sobmips!uunet!aplcen!samsung!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!+ From: Rick.Rashid@CS.CMU.EDU Newsgroups: comp.os.mach Subject: Re: Mach 2.5 bug Message-ID: Date: 16 Nov 89 14:54:45 GMT Sender: rfr@RFR.MACH.CS.CMU.EDU Organization: Carnegie Mellon, Pittsburgh, PA Lines: 22 The bug you describe has always been in Mach kernels and certainly is in our current versions. We have tried as much as possible to imitate the behaviour of 4.3bsd and the code for brk() was written explicitly to do so. I didn't work on that particular routine myself, but in similar situations in other parts of the bsd compatibility code we have similarly opted to preserve the actual workings of 4.3bsd rather than make up a new definition of behaviour that might be more logical. In cases where we have occasionally tried to modify the actions of bsd functions to better approximate the man page definitions, we have often discovered that user or vendor programs depend on the "incorrect" bsd implementation. This is the reason for our caution in making "corrections". In any case, the impact of this particular bug is only to prevent the actual release of the memory, not the semantics of brk() as defined in the man pages. In Mach terms, brk() does a vm_allocate if it expands the memory but does not do a corresponding vm_deallocate if it contracts. Programs will still work as advertised unless the brk() was actually needed to free up backing store. If you want to do that and you don't want to add the vm_deallocate to your kernel sources, you should simply call vm_deallocate explicitly after your call to brk. -Rick