[Mono-list] using 'unsafe struct *' instead of IntPtr with PInvoke..

[David Jeske]

On Thu, Dec 23, 2010 at 9:45 AM, Jonathan Pryor <jonpryor at vt.edu> wrote:

> In theory, this is safe (safer, really, as you get more type checking).
>

Thanks, that's exactly what I was looking for. Put differently, I was
looking for confirmation that "unsafe FOO*" is treated as a value type just
like IntPtr, so actual pointer contents will be left alone. It looks like
this is the case.


> In practice, it's more iffy for "social" reasons: unsafe code requires 'csc
> /unsafe', and some places don't like the '/unsafe' compiler flag.  The
> /unsafe' flag also marks the assembly as untrusted, so in certain CAS
> contexts you won't be able to use your assembly while you would be able to
> use the equivalent IntPtr code.
>

I don't understand. I'm asking this in the context of DllImport. Doesn't
using DllImport also require unsafe? I don't see how it would be possible to
DllImport using IntPtr without being "untrustable". I could munge the
IntPtr, call a DLLImported function and crash the machine.

> At a deeper level, I wonder why Platform Invoke doesn't advocate using
> > something like this more often, because it's alot safer than storing and
> > passing everything around as IntPtr.
>
> Then there's the Common Language Subset (CLS) viewpoint: unsafe code is NOT
> part of the CLS, while IntPtr/etc. IS, so IntPtr is more "portable" across
> languages targeting .NET, and thus more "general." Advocating IntPtr allows
> Microsoft to keep their documentation shorter and just write about the more
> general approach.
>

I see. If I export a CLS compliant interface with a C# module, while using
unsafe-pointers internally as a private part of my C# DllImport code, then
it's still find WRT CLS right?

Thanks for the answers. This is all telling me that there is no reason for
me to use IntPtr for DllImport module interfaces, as "unsafe struct
pointers" are simply safer and better. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20101225/93cbead8/attachment.html