At 04:07 PM 3/28/00 -0500, Dan Sugalski wrote:
>At 03:59 PM 3/28/00 -0500, [EMAIL PROTECTED] wrote:
>> "Craig A. Berry" <[EMAIL PROTECTED]> writes:
>> > At 01:52 PM 3/28/00 -0500, Charles Lane wrote:
>> >
>> >>+ I'm using LIB$(GET|FREE)_VM here so that we can allocate and deallocate
>> >>+ inside an AST routine without worrying about reentrancy and which Perl
>> >>+ memory allocator is being used.
>> >
>> > Mixing these with malloc() used to be a no-no; does the fact that you have
>> > them in an AST routine allow you to dodge that restriction?
>>
>>Do you mean "don't use one to allocate and the other to free"? I do keep
>>them separate in that regard (i.e., buffers from LIB$GET_VM are freed using
>>LIB$FREE_VM).
>
>It's got to be "alloc and free with the same library".
Actually it was something like "don't allocate some with malloc() and some
with LIB$GET_VM because you might get overlapping pieces," or something like
that. I don't really remember the details; perhaps the C RTL was doing
something nasty with zones. In any case, the Compaq C RTL doesn't use
LIB$GET_VM internally anymore, so mixing and matching is supposed to be ok.
>The Vax C RTL was pretty sloppy, but I can't imagine it completely forbidding the use
>of LIB$GET_VM. Well, I can, but that's going a little far even for it. (Might mess up
>sbrk, though, which could be why it was an issue)
sbrk is still messed up, if not being able to use it counts as messing up :-).
From the C RTL manual:
"The brk and sbrk functions assume that memory can be allocated contiguously
from the top of your address space. However, the malloc function and RMS may
allocate space from this same address space. You should not use the brk and
sbrk functions in conjunction with RMS and DEC C RTL routines that use malloc."
_______________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
