ax wrote:
"The benefits of running code in the managed environment of the CLR are
legion. For starters, as the JIT compiler converts CIL instructions into
native code, it enacts a code verification process that ensures the code is
type safe."
What does it mean by "type safe" here? Please give example about what
non-type-safe operations that native code can cause?
compile in release mode:
#include "stdafx.h"
class Class1 {
int local1;
};
class Class2 {
public:
int local1;
char local2;
};
int _tmain()
{
Class1 class1;
int test = 0;
Class2* pClass2 = reinterpret_cast<Class2*>(&class1);
pClass2->local2 = 'd';
printf("%d \n", &class1);
//note that &test == &pClass2->local2
printf("%d \n", &test);
printf("%d \n", &pClass2->local2);
//oops, we just set 'test' to 100, this is probably not exactly what we
//wanted,
//however it will compile and run just fine, possibly causing errors
//that are hard to track down
printf("%d \n", test);
return 0;
}
however, you can use reinterpret_cast on __gc pointers as well! There's
a verifiable switch in the compiler (at least with whidbey) and (without
testing) I assume you wouldn't be able to compile things with that
switch enabled (or when using c# (without the unsafe switch))
If you check the resulting executable with peverify, it will tell you
that the code is not verifiable.
It also has implications for "code access security" which you best look
up in the msdn library.
"You can't cast a type to something it's not because that operation isn't
type safe."
What does it mean by "cast a type to something it's not"?
"And you can't call a method with a malformed stack frame because the CLR
simply won't allow it to happen."
What's "a malformed stack frame"?
I'm not entirely sure what they mean by that, the two things i can think
of are:
1.
calling a function via a function pointer that has a different signature
than the function you're calling.
So you can call methods with different paramters than the function expects.
With managed code you would use delegates instead which are strongly typed
2. a buffer underrun can cause the stack to be overwritten which can
lead to serious security problems.
With pure managed code, buffer over-/underruns shouldn't happen at all.
hth
--
Ben
http://bschwehn.de 
