[Mono-devel-list] Overcoming PInvoke limitations in e.g. Mono.Posix

[Alan Jenkins]

PInvoke is convenient, but it relies on binary compatability.  E.g. much  
Posix specifications define symbolic constants for C programs which do not 
have a fixed value across all platforms.  The layout of structures also 
varies between platforms.  PInvoke is sufficient for the microsoft world, but 
Mono really needs more.  As far as I know the current Mono.Posix 
implementation doesn't have a complete solution - although I don't know 
anything about the SDL or GTK bindings.

I propose a Mono.InteropServices namespace, with tools to write structs and 
enums in C# from annotated (with attributes) C# code, with C code as an 
intermediate step.  The C code would be relatively portable, but the generated 
C# code would be platform specific.  Already generated C# code could be 
included for people without a C compiler (e.g. windows users).

I've been having a go at hand generating some C code first, but I'm quite 
willing & able to do the whole thing.  Theres only one bit which seems to 
involve any actual thinking - typedefs, which can be handled the same way as 
in Mono.Posix OEE 0.3:

Quoting Jonathan Pryor jonpryor at vt.edu
> Furthermore, C typedefs get their own types.  This feature is debatable,
> and can be changed, but I thought it was cool.  Consequently, the C:
> 
>         typedef unsigned long size_t;
> 
> Becomes the C#:
> 
>         public struct size_t : IComparable, IFormattable...
>         {
>                 private ulong value;
>                 // ...
>         }
> 
> This can get rather tedious, so I have a Perl script which generates the
> structure declarations, stub-vt.pl.  (This could also be a shell script,
> or any other language, if that would be preferred.  I'm not sure what
> the Mono policy regarding code generation is; I haven't heard of such a
> policy, anyway.)
> 
> The "typedef" classes all support implicit conversions to their
> underlying type, but require explicit conversions back.  Usage is thus:
> 
>      size_t a = (size_t) (1 + 2);
>         size_t b = (size_t) (a + 42);
>         // ...

Which sounds fine.

Stop me if this is already being worked on - I know its obvious, it's just 
nobody seems to have got around to it yet!  Unless I've missed something.

Alan