Hi, On Tue, 2009-11-10 at 09:10 +0100, pHilipp Zabel wrote: > Hi Yu,
> I still maintain that strm.next_in / strm.next_out cannot be owned > arrays because the call to strm.inflate changes the pointers > themselves. The same program compiles unchanged when I remove the weak > keywords again, but it fails when trying to destroy the buffers: > *** glibc detected *** ./zlibtest: munmap_chunk(): invalid pointer: > 0x000000000210b500 *** > I didn't know about this behavior. Could you kindly post me a copy of the CCode for zlibtest? I'd like to do some research on it and get this point clear. > The '->' argument doesn't apply here - uchar* vs uchar[], no structs involved. > But I agree that a single weak uchar[] is more Valaish than a uchar* and an > int. > The initial assignment is more compact this way: > strm.next_out = buf_out; > vs > strm.next_out = buf_out; > strm.avail_out = buf_in.length; > And I have to replace strm.avail_out with stream.next_out.length. > Other than that, > it's the same. So should we change that back (to weak uchar[]s)? > I definitely prefer using weak uchar[]s, as the field is an array but a pointer. If keeping the vapi similar to the original API is important, then you may consider add the avail_out field in the struct declaration and write a comment, stating that it is the same as next_out.length, and the mere purpose of that field is to keep the API consistent; or use (no_array_length=true) CCode attribute. PS: To get your patches applied, you have to let vapi maintaine know about your patch. See [http://live.gnome.org/Vala/BindingsStatus]. Yu > Thanks for having a look at this. > > regards > Philipp _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
