[cap-talk] "Managed code"

[Sandro Magi]

David-Sarah Hopwood wrote:
> Sandro Magi wrote:
>> What I've read of MS's documentation on managed code seemed pretty
>> consistent, though they never outright define "managed code".
> 
> Yes, they do:
> 
> <http://msdn.microsoft.com/en-us/library/aa719454%28VS.71%29.aspx>

I meant, they didn't define it in the docs I read, but I never really
went looking.

> # managed code
> #    Code that is executed by the common language runtime environment rather
> #    than directly by the operating system. Managed code applications gain
> #    common language runtime services such as automatic garbage collection,
> #    runtime type checking and security support, and so on. These services
> #    help provide uniform platform- and language-independent behavior of
> #    managed-code applications. See also: unmanaged code.
> 
> It is quite clear that this includes non-memory-safe, non-typesafe code
> provided that it is executed by the CLR. For example, "managed C++"
> is compiled to unverifiable MSIL code that is executed by the CLR, and
> therefore is "managed code" by this definition.

Seems an odd way of explaining the term, since unsafe "managed code"
does not benefit from automatic memory management, runtime type checking
or security support, since you could easily write a malloc
implementation using unsafe code.

As you suggest, the first line seems like the only relevant part, "Code
that is executed by the common language runtime environment rather than
directly by the operating system".

> Assemblies that are run with Full Trust are not verified. (See
> <http://www.owasp.org/index.php/Full_Trust_CLR_Verification_issue:_Changing_Private_Field_using_Proxy_Struct>
> for an example.)

I'm not sure how verification policy is relevant to managed code. Am I
missing something?

>> They use it as an equivalent for memory safe and type safe code executed
>> by the VM.
> 
> No, they don't, and the fact that you've gained that impression (as many
> people have) just shows how misleading the term is.

The precise meaning generally isn't important, since as I said, it only
comes up when dealing with P/Invoke. In 7+ years of C# programming, I've
touched P/Invoke once about 4 years ago.

>> I don't think there's a term that so accurately captures this
>> distinction, as simple memory safety or VM bytecode is insufficient.
> 
> What would be wrong with "MSIL code" or "CLR code"?

Given the above definition, MSIL/bytecode/CLR code, etc. would suffice.

If they intended to include only code that benefits from GC, type
safety, etc., which their follow-up sentences imply, then the fact that
MSIL can express programs that violate memory and type safety means MSIL
is insufficient.

Sandro