[Mono-list] IntPtr safety (was: need some help with PInvoke..)

[David Jeske]

Looks like my PInvoke and Marshaling lesson is done. Thanks again for
the great help! This post is just a few general discussion comments on
IntPtr wrt VB and Security.

On Thu, Jul 10, 2003 at 02:13:33PM -0400, Jonathan Pryor wrote:
> Well, to speak on .NET's behalf, .NET has a highly flexible security
> system.  You can't invoke DllImported functions unless your app has the
> appropriate security rights -- generally, that the app is running on the
> local machine.  If you're running it from a network share, or from a web
> site (similar to Java Applets), then your app will get a
> SecurityException.

Is there a way to disallow an assembly from calling any function which
takes an IntPtr paramater or void* paramater? It seems to me that this
would be required to stop sandboxed code from segfaulting the
system. Otherwise I can just hand an HWND IntPtr I get from "secure
ok" S.W.F code, and hand it to "secure ok" Gtk code, and poof. :)


> >  - If I want to reference the data in-place in unmanaged memory, I use
> >    an unsafe struct and a struct pointer.
> > 
> >  - Since an IntPtr is basically a void*, I don't see why I would ever
> >    use it, unless the external call actually takes a void*.
> 
> You would use it if you need to expose the member to languages other
> than C#/C++.  For example, Visual Basic has no syntax for "unsafe" code,
> and thus you couldn't use Visual Basic to perform your 2nd option.  If
> you want your code to be usable by other languages, you'll need to
> provide an appropriate wrapper.

I guess this is my confusion. HWND* is _safer_ than IntPtr, because it
is a pointer to a specific type. It's the operations on HWND* that are
unsafe. It seems like it would be better if VB (and other languages
without unsafe) had the ability to express HWND*, and simply not
operate on it.

Certainly this:
    .field  public   valuetype HDF* p

Is better than this:
    .field  public   native int p

Ohh well... maybe it'll get in the queue for .NET 2.0. although I'm
much more excited about parametric types than I am worried about this.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net