Hello Vasili,

Thursday, August 7, 2008, 9:33:32 AM, you wrote:

oh, it was my mistake. alloca behavior is completely defined by it's
generic implementation:

allocaBytes      :: Int -> (Ptr a -> IO b) -> IO b
allocaBytes size  = bracket (mallocBytes size) free

although GHC implementation is much more efficient

btw, why you can't download ghc library sources and read them yourself??

> If I am correct, I cannot associate a ForeignPtr with alloca or
> allocaBytes object via "newForeignPtr" because the
> alloca/allocaBytes heap object will be GC'd when I leave the
> function that allocated this object/. I.e. if I have a heap object
> that I want to live beyond a function invocation, I must be very careful in coding....
>
> Vasili

> On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili <vigalchin@gmail.com> wrote:
>
> so Bulat ..

>      You seem to be saying what I suspect ... i.e. if an
> allocaBytes call is inside a function, when the function is exited
> then the said heap object is GC'd??

> Regards, Vasili
>

>

> On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin
> <bulat.ziganshin@gmail.com> wrote:
>  Hello Vasili,
>

>  Thursday, August 7, 2008, 9:13:43 AM, you wrote:
>
 >>     What is the lifetime of various heap objects ... e.g. created by allocaBytes, alloca, etc?
>
>
> alloca/allocaBytes just mimicks stack allocation but actually allocates
>  buffer in usual heap. this buffer lives while references to it exists
>
>  on practice, it's usually gc'ed by next minor GC
>
>  --
>  Best regards,
>   Bulat                            mailto:Bulat.Ziganshin@gmail.com
>
>

>

>

--

Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com