[MERGE-REQUEST] New `aggregated' typespec

[Ludovic Courtès]

Hello,

Here is the patch of the day:  a new `aggregated' typespec -- don't be
afraid, I'll probably slow down now.  ;-)

  patch-7
      Added support for the new `aggregated' typespec;  fixed use of `long 
long'.


What I'm trying to address
--------------------------

Imagine the following C API:

  /* Return a new stuff.  */
  stuff_t *make_stuff (void);

  /* Return a stuff container that contains a pointer to CONTAINED.
     Note that the container returned is _not_ responsible for
     deallocating the resources attached to CONTAINED.  */
  stuff_container_t make_stuff_container (stuff_t *contained);

And now, imagine the following Scheme code that uses bindings of the
above functions:

  (define c (make-stuff-container (make-stuff)))

Suppose the two C types are wrapped as WCTs.  The call to `make-stuff'
will create a new WCP (a SMOB) for the underlying C object.  However, as
soon as `make-stuff-container' has returned, the Scheme code no longer
holds any SMOB representing the value that was returned by
`make-stuff'.  Consequently, the `wcp-free-function' attached to the WCT
<stuff> will soon get called, freeing the C object originally returned
by `make_stuff ()'.

But, here is the problem:  the C `stuff_container_t' object still contains
a pointer to that `stuff_t' object that has just been deleted!  We need
a way to solve this problem:  a whole new `aggregated' typespec will
hopefully do the trick.  :-)

Note that GTK bindings do have similar problems:  think of
`gtk_container_add ()' and the likes.  However, I believe this problem
is solved very simply by reference counting.  So my proposal targets C
APIs that do not use reference counting.


How it works
------------

The solution I propose adds a new `aggregated' typespec.  This should be
used with input arguments to functions that return a new WCP (either as
a return value or as an `out' parameter) that aggregates the argument(s)
in question.  In the example above, we have to do the following:

  (wrap-as-wct! ws
                #:name '<stuff>
                #:c-type-name "stuff_t *"
                #:c-const-type-name "const stuff_t *"
                #:allowed-options '(aggregated))

  (wrap-function! ws
                  #:name 'make-stuff-container
                  #:c-name "make_stuff_container"
                  #:returns '<stuff-container>
                  #:arguments '(((<stuff> aggregated) stuff)))

A new function, `gw_wcp_set_dependencies ()', has been added to the
run-time support so that wrapper functions (or `dynproc_smob_apply') can
specify a list of SMOBs a WCP depends on.  In the example above, once
the `stuff_container_t' SMOB has been created via
`gw_wcp_assimilate_ptr', the function <stuff> argument is put into the
list of dependencies of that new SMOB.  Any SMOB that appears as a
dependency of a WCP will not be freed (IOW, it will keep being marked)
until the WCP that depends on it is also freed (and the SMOB is no
longer available from Scheme code).

Dependencies are simply implemented using Guile object properties.  The
list of dependency is used as the value of a property of the WCP being
returned.  Therefore, no reference counting is needed, Guile's GC does
all the job.


The patch adds a tiny test case for this.  Incidentally, it also fixes a
couple of things regarding the use of `long long' integers in the
standard wrapset (namely the fact that this is a GNU C or C99 type, and
the `LLONG_' macros are not defined when compiling ANSI C).

I hope this was clear enough.  I'd be glad to discuss this if you think
it really looks too weird.  ;-)

Thanks,
Ludovic.