pete@titan.rice.edu (Pete Keleher) (08/18/89)
I recently ran into a bug that could be easily explained if it were the case that 'NewPtr' grabs an entire memory block, even if you only want a very small block (<100), thus removing the unused portion of the block from any useful activity. Please say it ain't so.... -- =========================================================================== Pete Keleher pete@titan.rice.edu Rice University knows nuttin about what I say, or what I do ... ===========================================================================
jct@geology.wisc.edu (John C. Terranova) (08/20/89)
In article <PETE.89Aug18092724@titan.rice.edu> pete@titan.rice.edu (Pete Keleher) writes: > >I recently ran into a bug that could be easily explained if it were the >case that 'NewPtr' grabs an entire memory block, even if you only want >a very small block (<100), thus removing the unused portion of the block >from any useful activity. Please say it ain't so.... It ain't so. The smallest number of bytes that the Memory Manager will allocate for you is 12. If you request >=12 bytes you will receive exactly what you ask for (even padded). There is, of course, an 8 byte header for every memory block. There is some other explanation for your bug. >Pete Keleher pete@titan.rice.edu +----------------------------------------------------------------------------+ | John Terranova <-- me disclaimer --> What the hell do I know? | | jct@ice.geology.wisc.edu <-- address I come from Waunakee! | +----------------------------------------------------------------------------+ song lyric: We'll drive into the sun and maybe never comin' back. We're goin' cruisin'. Do you want to come? Cruisin'. Do you want to come along with me? -- Gerard, Cruisin'
fang@physics.phy.duke.edu (Fang Zhong) (02/05/91)
-- Fang Zhong 1-919-684-8247 Duke University Dept. of Physics fang@phy.duke.edu Durham, N.C. 27706
KPURCELL@LIVERPOOL.AC.UK (02/11/91)
In article <21948@duke.cs.duke.edu>, fang@physics.phy.duke.edu (Fang Zhong) says: > >-- > Fang Zhong 1-919-684-8247 > Duke University Dept. of Physics fang@phy.duke.edu > Durham, N.C. 27706 Apologies for the wasted bandwidth -- but this message appears to have the same problem I have with the memory manager (its a NIL handle!). _ . Kevin Purcell | kpurcell@liverpool.ac.uk _/ \ / \ kgp@cxa.dl.ac.uk Surface Science, | /----/^^^\ Liverpool University | There is now a damm fine /TWIN PEAKS\ email discussion Liverpool L69 3BX, UK | list for TPers. Mail me / / \ for details.
Ron Smith (06/18/91)
This is a pretty simple question, and I've been getting along fine without asking, but I'm starting to get curious, how does one allocate all the memory possible to 1 pointer. I've been using these 2 lines I found in someone else's source (I don't think they should mind)... size=MaxMem (&grow); size-=65536; now, do a NewPtr (size); actually, it used to be: size=MaxMem (&grow); size-=32768; (for one code segment?) but I doubled the number to accommodate 2 code segments, the one currently active, and the main one, since I wasn't doing this from the main one. The "size-=32768" IS to not run over the main code segment, right? anyways, it seemed somewhat silly to include the current code segment as purgeable space, I can't think of any instance when you would want to allocate over it. So my question is, is there another way to allocate all the space possible (not including any active code segments)? --RS (rps32513@uxa.cso.uiuc.edu)