[Mono-list] PInvoke Conventions

[Rhys Weatherley]

Miguel de Icaza wrote:

> I read the article, and I believe that the problem is even more
> complex than it looks like at first examination.
>
> The particular case you show (lseek) as well as other POSIX APIs does
> not use int or longs.  They use things like `off_t', `size_t', `struct
> stat' which are part of the specification.

I started to address this in the "ANSI C Types" section, but
it was a little rushed prior to putting the document up.

> Your proposal does not solve the problem of structures, and I am
> afraid that adding even more attributes is not going to help out.

You may be right.  "stat" is certainly a problem.

> There are a couple of solutions to the problem:
>
>         * Get the ECMA specification to specifically list some core
>           types (off_t, size_t) and map those to NATIVE_POSIX_XXX.

While they are at it, they should add NATIVE_TYPE_LONG and
NATIVE_TYPE_ULONG to marshal system-specific "long" and
"unsigned long" values.

>         * Have the compiler produce out-of-band data to "annotate" the
>           real types automatically, ie:
>
>           [DllImport("libc")] lseek (int fd, off_t off, int pos)
>
>           off_t would be a ValueType annotated with [System.POSIX]

This would make it difficult to compile the library with third
party tools, such as Microsoft's C# compiler.

>         * Have a new PInvoke invocation that does not require extra C#
>           types:
>
>                 [DllImport("libc"),PosixProto(int,off_t,int)]
>                 int lseek (int, long, int)
>
>                 [DllImport("libc"),PosixProto(string,struct.stat *)]
>                 int stat (char *, struct stat *)

I actually like this idea of using attributes to specify an
alternative prototype.  I'll think about it over the weekend as
I update the document with what has been discussed so far.

> Have the CLI runtime or the autoconf process figure the proper sizes
> of the various POSIX type definitions at compile time.  It should also
> figure out the layout of public structure fields for POSIX structures.

This assumes that there will be different library builds for each
platform.  This may not be too bad for core stuff, but may be a
hassle for extension libraries.

The key issue actually isn't how to make PInvoke work, but rather
to make it work the same.  An application that imports "lseek"
needs to work regardless of how the call is marshalled to the
underlying OS.  When the application is compiled, the method
signature will be placed into it by the compiler.  It can only run
if the CLR/library exports a method with the correct signature.

So, autoconf would need to detect the exact system
characteristics and then write out marshalling information
to convert the agreed-upon method signature into the
system-specific one.

Cheers,

Rhys.

P.S. My Web site is off the air at the moment due to a router
failure at my hosting company.  It should be resolved soon.
Apologies to those trying to get the "pinvoke.html" document
in the meantime.