What is unsafe in this code?

I am learning managed and unmanaged code in the CLR. So I wrote this example with C style pointers in C #:

unsafe static void Main(string[] args) { int x; int* y; y = &x; *y = 50; Console.WriteLine(*y); Console.WriteLine(((int)y).ToString()); } 

So, I am wondering what is actually unsafe in the IL code that I received from the code above?

 .assembly extern mscorlib {} .assembly UnsafePointers {} .module UnsafePointers.exe .class private auto ansi beforefieldinit UnsafePointers.Program extends [mscorlib]System.Object { .method private hidebysig static void Main(string[] args) cil managed { .entrypoint // Code size 34 (0x22) .locals init (int32 x, int32* y) IL_0001: ldloca x IL_0003: conv.u IL_0004: stloc y IL_0005: ldloc y IL_0006: ldc.i4 50 IL_0008: stind.i4 IL_0009: ldloc y IL_000a: ldind.i4 IL_000b: call void [mscorlib]System.Console::WriteLine(int32) IL_0010: nop IL_0011: ldloca y IL_0012: conv.i4 IL_0016: call instance string [mscorlib]System.Int32::ToString() IL_001b: call void [mscorlib]System.Console::WriteLine(string) IL_0021: ret } } 

Does the CLR support this code? And what could go wrong with the code above?

+8
pointers c # clr unsafe il
source share
5 answers

What makes this code unsafe is the use of the ldind.i4 operator. This loads the signed 4-byte integer from the memory address. You can specify any memory address that allows reading from any memory address in the current process. This is considered unsafe and untested. For example, you can use this to look inside other applications that are not allowed.

+6
source share

It is called unsafe, partly because it is not controlled.

You can easily create C ++ style memory leaks, there are no border checks and other problems ...

A good article on unsafe code also lists several risks:

Using unsafe C # code

+6
source share

Insecure, perhaps does not mean that it is dangerous, but one thing is important in insecure code: it is not checked . This can mean several things, for example, not checking the boundaries of the array. In your simple example. there is nothing dangerous or terrible about it. This is pretty straight forward.

In may be unsafe because it also covers most of the security mechanisms in the .NET Framework; therefore, unsafe code requires Full Trust.

Unsafe! = Uncontrollable. Unsafe simply means that it can manipulate pointers.

+4
source share

In the general case, the unsafe keyword allows you to access memory directly and therefore bypass all security and security checks using the CLR.

Here is a good article on the use and impact of unsafe code: http://blogs.msdn.com/b/sebby1234/archive/2006/04/05/565090.aspx

+3
source share

By default, Microsoft C # and Visual Basic.NET compilers create “safe” code. Safe code is code that is authentically safe. However, using the C # s unsafe keyword or using other languages ​​(for example, C ++ with managed extensions or the IL assembly language), you can create code that cannot be reliably safe. That is, the code can be really safe, but verification cannot prove it.

the administrator can choose to disable verification (using the Microsoft .NET Management snap-in "Management Console"). When checking is turned off, the JIT compiler will compile the untestable IL into its own CPU instructions; however, the administrator is solely responsible for the behavior of the code.

0
source share

All Articles