[vlc-devel] CIL bindings and brain dump on LibVLC

[Rémi Denis-Courmont]

On Mon, 22 Oct 2007 09:29:21 +0200, Boris Dores <babal at via.ecp.fr> wrote:
>   If a true C int is unavoidable, the corresponding CIL type would
> be IntPtr, even if the name is somewhat misleading ( from MS
> doc: "The IntPtr type is designed to be an integer whose size is
> platform-specific. That is, an instance of this type is expected to be
> 32-bits on 32-bit hardware and operating systems, and 64-bits on 64-bit
> hardware and operating systems." )

A "true C int" is 32-bits on LP64 (incl. Linux amd64/x86_64) and LLP64
(incl. Win64) platforms. I have always assumed that CIL IntPtr maps to
C intptr_t (i.e. integer type whose entropy is that of a pointer), and
your statement confirms that. As such I expect IntPtr to be 64-bits
on LP64 and LLP64 platforms, whereas both native and CIL int are 32-bits.

Of course, IntPtr might work regardless, if the native calling
convention pads 32-bits integers to 64-bits, but... hmm?

>> It gets interesting when you consider that you cannot provide native
>> "glue" C code here, since it would defeat the whole CIL concept of
>>"compile once, run anywhere". In other words, any piece of code beyond
>> libvlc-control is to be compiled in CIL. So basically, anything that
>> uses int may be somewhat broken, 
>> and anything that uses bool or enum is somewhat more likely broken.
> 
>   But you can provide the import class (and possibly the corresponding
> precompiled library for various platforms) which will do all the
> necessary checks, conversions and dirty work and so will not be broken
> (lots of things can be done in such an import library).

No. We cannot realistically ship an import library for each supported
platform. What we can do, is "fix" libvlc-control or add fixed-size
integers API variants to it.

>   If a release order (from the CIL point of view) is unavoidable or if a
> resource must be freed at a specific time, implement IDisposable (of
> course, if the native library is designed not to need it, it's better).

I do use SafeHandle and IDisposable where appropriate.
That's not the point.
Neither IDisposable nor SafeHandle can warrant proper "release" ordering
when one handle depends on another handle, because the GC itself does not.
As far as I can tell, the only solutionis reference counting,
either natively or using adequately named SafeHandle.DangerousAddRef().

-- 
Rémi Denis-Courmont
http://www.remlab.net/