Fri, 27 Jul 2001 11:30:17 +1000
Fergus Henderson wrote:
> The syntax is quite elegant, but you're pushing a lot of the complexity into
> the VM engine.
> How exactly is the VM engine supposed to handle the [PosixType] custom attribute?
> Is it supposed to have a hard-coded list of types and their layouts,
That's the assumption, yes, and it _is_ a drawback of this
approach. Any other approach will need something equally
yucky. Something somewhere needs to know how what the
real underlying type is. Either the VM does it, or we #ifdef
the C# library to compile differently for platforms with
different type sizes. The VM-based mechanism is the
> and to report an error if the type name doesn't match one of the types in
> its hard-coded list?
There's two ways to handle this case: raise an error, or
make a guess. In the definitions in my previous message,
the "value" field was declared as "int" for "int_t" and as
"long" for "off_t". This information could be used to guess
the native counterpart in the absence of other information.
For example, consider the following definition of "size_t":
public struct size_t
private uint value;
... constructor and conversion operators ...
If the VM didn't know about "size_t", it could guess
from the type of "value" that a "native unsigned int"
was intended. It's another one of those "least yucky"
I am becoming a little concerned though that the PInvoke
mechanism will involve a huge amount of code to
implement in any given VM. This increases the chance
of error, and hence interoperability will be affected.