Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Unsafe code is not managed

I think that unsafe code is not managed.
In the following unsafe code, a wild write trashes
the IO system.

At least, that's what it did on my machine.
Run it at your own risk.

public
class UnsafeIsNotManagedExample {

public
static
void Main(string[] argv) {
  int[] managedArray = new int[10];
  unsafe {
    fixed( int *p = managedArray ) {
      for( int i=0; i<1000; ++i )
        p[i] = i;
    }
  }
  System.Console.Out.WriteLine("OK");
}

}

Tom Cargill
Friday, September 20, 2002

Thats why its called unsafe code. Its not managed by the CLR. Thats why is not recommended to use.

Pierre
Friday, September 20, 2002

Sorry. I should have said that in the

  Is unsafe more efficient?

thread, the claim was made that unsafe code is
managed, to explain why it's no faster.

I'm beginning to think that's it's 'half-managed'
so that some of the checks associated with
managed code are applied in unsafe code,
while others aren't.

Tom Cargill
Friday, September 20, 2002

There is a difference between unmanaged code, and unsafe managed code.  Unmanaged code is (typically) plain x86 instructions.  Unsafe managed code is IL instructions that are allowed to perform unsafe actions when the security policy allows.

The difference is that with managed code you can determine that there is no unsafe code in the assembly.  Take a look at PEVerify.exe to determine if the code is safe.  You can also use Caspol.exe to set a security policy.

If you try to run your example program from a net share, you'll see you get an exception before the unsafe code is run.

Steve Steiner
Friday, September 20, 2002

Thanks, Steve. This helps.

So there are three levels:
managed
unsafe
unmanaged

It appears that the level of checking for unsafe
code is implementation-dependent. For example,
item 7 of section B.2 of the C# spec. And the
MS engine (at present) happens to throw an exception
for *p when p is null, which begins to explain
why unsafe code is no faster than managed code.

Tom Cargill
Friday, September 20, 2002

No, it's not three levels, it's two levels:

Managed
Unmanaged

Additionally, code that is managed can be marked "safe" or "unsafe".

The .NET Guy
Wednesday, September 25, 2002

"it's not three levels, it's two levels, managed and unmanaged"

combined with

"additionally, code that is managed can be marked safe or unsafe"

is not very different from having three levels in the first place, you know :)

Bill
Wednesday, September 25, 2002

The terminology is a bit confusing here. I'll try and obscure... I mean, explain things.

Unmanaged code is plain old x86 machine code. It's raw CPU instructions, and can do anything. It has no support from, and no interaction, with the runtime.

Managed code DOES use and depend on the CLR. The CLR knows about the stack layout of managed code, and can do things like handle memory management, stack walks for security checks, check for array overwrites, etc. Managed code is typically persisted as IL rather than machine code and JIT compiled at load time.

So, the big difference between managed and unmanaged: In managed code, the runtime knows what the code is doing, understands the stack and object layouts, and can provide support for that code. In unmanaged, the runtime is hands off.

Safe and unsafe refer to what the code is allowed to do. Since the runtime doesn't touch unmanaged code, it is be definition unsafe, since it can do anything the OS allows.

Safe code is checked by the runtime to make sure that pointers don't wander out of their allocated areas, security checks are done, that sort of thing. Unsafe code is marked with an IL attribute that says "I need to go outside the box here, trust me." The runtime WILL allow unsafe code access to raw memory and arbitrary addresses, but the host of the runtime (Internet Explorer or ASP.NET, for instance) can set up the runtime such that unsafe code will not be allowed to run.

So, the two concepts are actually orthorgonal.

Hope that helped,

-Chris

Chris Tavares
Wednesday, September 25, 2002

*  Recent Topics

*  Fog Creek Home