Bugzilla – Bug 313738
GByteArray support
Last modified: 2007-09-15 21:23:44 UTC
---- Reported by joeshaw@novell.com 2004-01-28 18:26:40 MST ---- There should be some glue between C# and GByteArray. Attached is a patch which implements it. ---- Additional Comments From joeshaw@novell.com 2004-01-28 18:36:23 MST ---- Created an attachment (id=165551) proposed patch ---- Additional Comments From joeshaw@novell.com 2004-01-28 18:38:35 MST ---- Err, to be more clear: this is just a first pass... it hasn't really been tested since i've been having problems with getting mono to resolve the .dll to a .so, but I wanted to make sure I was barking up the right tree. ---- Additional Comments From mkestner@ximian.com 2004-01-29 17:37:22 MST ---- I'm thinking we should probably do this with custom marshaling instead. I don't think we really need to expose a wrapper for GByteArray. Instead we should generate those parameters as byte[] and marshal the managed byte[] to a GByteArray. Unfortunately, my first custom marshaler implementation for DateTime to time_t marshaling just exposed a bug in mono. ;-) ---- Additional Comments From joeshaw@novell.com 2004-01-29 18:09:21 MST ---- Ooh, I totally agree. How do you do stuff like this? ---- Additional Comments From mkestner@ximian.com 2004-01-30 17:52:26 MST ---- take a look at glib/time_t_CustomMarshaler.cs on cvs. and here's an URL to kinda explain what's going on: http://www.developer.com/net/cplus/article.php/3101771 ---- Additional Comments From joeshaw@novell.com 2004-02-02 13:25:02 MST ---- I looked at the code, but it is not obvious to me at all. What's the reason for the offset? How does this work with a more complex data type like GByteArray, and how do you get it to return it as a byte[] ? (Thing is, we're probably going to need this sooner rather than later for rcd) ---- Additional Comments From mkestner@ximian.com 2004-12-28 14:03:30 MST ---- I was looking into GByteArray and I need a little more information on how this is used. I only see one instance of its use in the currently bound Gtk# library set, on a method in gtkhtml. It's a method that takes a GByteArray parameter. I'm unclear why anybody would expose GByteArray API, to be honest, because it seems to be a type designed for manipulating/assembling byte arrays from multiple byte streams. It seems like the kind of thing a library might use internally, or an app developer might use to assembly a byte array to pass to a library, but it seems to me that I'd be more inclined to take the assembled array data instead of the GByteArray as a parameter. There are also issues about ownership. Even if a caller retains ownership of the GByteArray, there is a question of ownership of the data since the free call requires instructions as to whether to release the underlying data. I'm skeptical as to whether this type kind be reliably bound. ---- Additional Comments From joeshaw@novell.com 2005-01-06 21:43:44 MST ---- The library in question is librcd. It has a few methods that return a GByteArray, mostly surrounding its network data. Check this out for an example: http://cvs.gnome.org/viewcvs/rcd/src/rcd-transfer.h?view=markup notably, rcd_transfer_begin_blocking(). All the data for an RCDTransfer object is stored in a GByteArray (so we'd actually need to add an accessor for the non-blocking case). I think ideally, since a GByteArray in C and a byte[] in C# are essentially the same, that some marshalling magic would transparently bind and do any necessary conversions. The lifecycle issues do exist there, but you might be able to do a fairly good job guessing based on whether it has "const" for a return value and then use metadata hints (like you have need_ref on objects now) to tune it. I'm not working on Red Carpet anymore, and both tambet and snorp have gotten most of the APIs bound anyway (the details of which I'm not familiar), so it might be something we can just close WONTFIX. Either way, it probably won't affect me all that much, but it'd be a nice thing to have if feasible. Imported an attachment (id=165551) Unknown operating system unknown. Setting to default OS "Other".