At 03:37 PM 3/28/00 -0600, Craig A. Berry wrote:
>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.

I hope they fixed it for Dec C. I'd hate to think there are versions of the 
C RTL kicking around that are still dangerous like this.

> >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."

Ah. Well, no huge loss--sbrk's kinda lame anyway, and the perl malloc stuff 
will use the system malloc unless you explicitly tell it not to, so we're 
OK. (It also doesn't work in 5.6.0. I'd have fixed it but I kept thinking 
we'd actually get a *release*...)

                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to