Bug 313738 (MONO53495) - GByteArray support
Summary: GByteArray support
Status: CONFIRMED
Alias: MONO53495
Product: gtk#
Classification: Mono
Component: other (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Enhancement
Target Milestone: Future
Assignee: Gtk# Bugs List
QA Contact: Gtk# Bugs List
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2004-01-29 01:26 UTC by Joe Shaw
Modified: 2007-09-15 21:23 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
proposed patch (3.75 KB, patch)
2004-01-29 01:36 UTC, Thomas Wiest
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 18:25:53 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".