[Mono-list] PInvoke Conventions

[Tomas Restrepo]

Hi Rhys,

> It may not be necessary to add an extra attribute either.  The
> CLR spec already has a way to specify that a class has "explicit
> layout".  Right now, it assumes that the programmer will provide
> the offsets of the fields and the packing details to use for the
> class.

That's correct. Personally, I don't see much need to overload it. But that
aside, I don't see the problem of dealing with native sized values as such a
big deal. While nor the ECMA, nor MS say it a lot, using P/Invoke does, in
more ways than one, leave platform independence out of the question.
Besides, even if you do support it, I don't see that as such a big
improvement, since in the case you cite with structs and other cases, using
native types for integral types in interop still leaves you with the  big
trouble of what to do if the underlying native type is larger than the
declared one in C# (i.e. the struct has int, but you use a 64-bit value
underneath). What do you do if you have to marshal both ways? This is being
discussed elsewhere on this thread, I know, but either possibility is going
to bring it's own set of problems, and worse, it's own set of unexpected
side effects, causing developers pretty ugly to debug cases (which is
already a problem in P/Invoke).


> Sam, perhaps it could be adjusted slightly to say "if the
> class is marked explicit, but no explicit information is supplied,
> then use the platform-specific conventions".

Isn't that what SequentialLayout means, anyway? The ECMA spec doesn't say it
out loud, but I presume it is expected to use the default packing in that
case. If, instead it implies a packing of 1, then one could suggest the
attribute is extended to support an argument telling it what packing to use,
which seems clearer that using explicit in this case (at least to me).

--
Tomas Restrepo
tomasr@mvps.org