Re: bad free after iter->to_arrayref

[Kevin Ryde <user42 zip com au>]

muppet <scott asofyet org> writes:
> Yeah, it sucks.

Looks like the C level inhales too, really.  Ok for in-memory, but hard
work if your data is say out on disk.

> Alternatives involve putting quite a bit of magic into the bindings at  
> this point, which would pretty much turn into a custom model of its  
> own from which you'd derive another.

I guess perl magic can't get around an iter being merely 3 words of
uncontrolled data at the C level.

My only thought might be to let a flag in the class say if it wants to
treat its iter data as integers instead of refs, for flexibility.

> "if you build it, they will come").

Personally I always get bookings first.  A bloke out in the desert once
told me that if you book them they will come.  :)


A couple of words for the docs to perhaps keep the unwary out of
trouble:

--- GtkTreeModel.xs     10 Jan 2008 09:51:09 +1100      1.52
+++ GtkTreeModel.xs     27 Apr 2008 10:51:38 +1000      
@@ -565,14 +565,22 @@
 
 =item o user_data2 (scalar)
 
-An arbitrary scalar.  Will not persist.  May be undef.
+An arbitrary reference.  Will not persist.  May be undef.
 
 =item o user_data3 (scalar)
 
-An arbitrary scalar.  Will not persist.  May be undef.
+An arbitrary reference.  Will not persist.  May be undef.
 
 =back
 
+The two references, if used, will generally be to data within the model,
+like a row array, or a node object in a tree or linked list.  Keeping the
+things referred to alive is the model's responsibility.  An iter doesn't
+make them persist, and if the things are destroyed then any iters still
+containing them will become invalid (and result in memory corruption if
+used).  An iter only has to remain valid until the model contents change, so
+generally anything internal to the model is fine.
+
 =head2 VIRTUAL METHODS
 
 An implementation of