GNOME Bugzilla – Bug 794409
BZLib - bzalloc/bzfree
Last modified: 2018-04-15 17:46:10 UTC
Created attachment 369800 [details] [review] Patch that adds bzalloc/bzfree Vala provides a good API for bzlib. However, one might want to set the allocator function. Currently, this requires me to have a C function that takes a (ref BZLib.Stream) and sets its allocator in C code. This is definitely not what I'd expect from a complete binding. This bug is reproducible in both Vala 0.34.7 (Debian stretch) and Vala git/master. I've attached a hand-crafted patch. It might need modification, but it definitely solves the problem. NOTE: Do not remove the has_target attribute in the delegates! The void* argument is a target common to bzalloc/bzfree, so it cannot be used as a Vala closure.
Thanks, could you attach a small test-case which is using those symbols. Maybe even a running one.
Unfortunately, I'm afraid it is impossible unless Vala supports undeclared callbacks in VAPIs. Would you mind marking this bug as dependant on a bug about undeclared callbacks or reporting it? Thanks in advance.
(In reply to Jakub Kaszycki from comment #2) > Unfortunately, I'm afraid it is impossible unless Vala supports undeclared > callbacks in VAPIs. The request was to have a working example that uses your proposed patch so the patch could be tested. Are you saying your patch doesn't work at all because of another bug in Vala? > Would you mind marking this bug as dependant on a bug about undeclared > callbacks or reporting it? Declaring callbacks (delegates) is part of the type system in Vala. It makes sure a callback has the right function signature (that's the function parameters and return value). Vala has a strong type system similar to C#. You seem to be saying that the strong type system is a bug?
For reference the documentation is here: http://www.bzip.org/1.0.5/bzip2-manual-1.0.5.html#low-level The C struct is: typedef struct { char *next_in; unsigned int avail_in; unsigned int total_in_lo32; unsigned int total_in_hi32; char *next_out; unsigned int avail_out; unsigned int total_out_lo32; unsigned int total_out_hi32; void *state; void *(*bzalloc)(void *,int,int); void (*bzfree)(void *,void *); void *opaque; } bz_stream; The documentation states: "Custom memory allocators are supported, via fields bzalloc, bzfree, and opaque. The value opaque is passed to as the first argument to all calls to bzalloc and bzfree, but is otherwise ignored by the library. The call bzalloc ( opaque, n, m ) is expected to return a pointer p to n * m bytes of memory, and bzfree ( opaque, p ) should free that memory. If you don't want to use a custom memory allocator, set bzalloc, bzfree and opaque to NULL, and the library will then use the standard malloc / free routines." For documentation purposes I think the parameters should make it clearer bzalloc is expecting the number of bytes: public delegate void *AllocFunc (void *target, int m_bytes, int n_bytes);
Created attachment 370964 [details] [review] bzlib: Add bzalloc/bzfree fields to Stream
Attachment 370964 [details] pushed as c3621d0 - bzlib: Add bzalloc/bzfree fields to Stream