I had a brainbench exam recently, got high mark, but there were a couple of questions which were hard for me. Maybe it's because english is not my native language... One of the questions is:
Which one of the following describes type-safety?
- A programming construct used to ensure the security of reference and value types in the CLR
- The protection from memory leakage as a result of disallowing unmanaged access
- The CLR-specific feature providing assurances that types may not access memory outside their own AppDomain
- A mechanism created to protect assemblies and their types by the use of strong-named keys
- The concept dealing with assurances that allocated objects are always accessed in compatible ways
I think it's 1 or 5, but they sound weird to me anyway :(
What do you think?
Actually I think it's Choice 5 because type safety has nothing to do with Security.
Type Safety is the feature of a language designed to make good on [Robin Milner][1]'s famous slogan about ML programming: well-typed programs cannot go wrong.
The slogan needs some unpacking before it can be properly understood, but it basically means that programs cannot fail because of a runtime type error, i.e. when the parameters applied to constructor or a function have values of incompatible type.
Consider a language that allows integers, integer functions as first class values, function abstraction and partial function application, and which defines the usual integer arithmetic operators as binary functions. The property of type safety is what the compiler enforces to ensure that both of the arguments to the addition operator are expressions that reduce to integers and not to functions. If a program is well-typed, then the compiler can emit an executable object for it. Otherwise, it flags the programming error and aborts.
According to the msdn link provided below,
http://msdn.microsoft.com/en-us/library/hbzz1a9a.aspx
Type-safe code accesses only the memory locations it is authorized to access. (For this discussion, type safety specifically refers to memory type safety and should not be confused with type safety in a broader respect.) For example, type-safe code cannot read values from another object's private fields. It accesses types only in well-defined, allowable ways.
Choice 5
The concept dealing with assurances that allocated objects are always accessed in compatible ways
Type-safety deals with ensuring that when you create a Foo, you can't treat it as a Bar. If you don't know what type it is (or aren't guaranteed), the code you write simply might not work as expected.
Type-safe languages will make sure (at compile-time) that you don't call incompatible methods on a type, e.g. length() on an int type. Non-type-safe languages will figure it out at runtime. So, choice 5.
As other have said, choice 5...
In general - for .NET, check out the Common Type System (CTS) which enables cross-language stuff and type safety.
Check out: http://en.wikipedia.org/wiki/Type_safety ...
It is option #5. Type safety is an assurance, not a concrete thing. It is possible for .NET code to not be type safe...say in the case that an assembly uses unsafe code to perform unmanaged calls (PInvoke). During JIT, a process is performed that verifies the types being jitted are, indeed, type safe. I am not aware of any particulars about this process, but if a jitted type passes, then it is considerd verifiably type safe.
