[bitc-dev] Inner references, regions, and CLI
naasking at higherlogics.com
Thu Mar 24 08:59:58 PDT 2011
"internal" corresponds exactly to "assembly" accessibility. I confirmed
by dissassembling some of my own code to check how it's represented, and
your description of "Assembly" matches exactly MS's description of
On 24/03/2011 11:38 AM, Ben Kloosterman wrote:
> This is the case for C# but I internal does not exists in the CLI its mainly
> just public or private ( note worst case private methods may be discovered
> , stored as delegates and even invoked via reflection )
> Private 0x0001 Accessible only by the parent type
> FamANDAssem 0x0002 Accessible by sub-types only in this Assembly
> Assembly 0x0003 Accessibly by anyone in the Assembly
> Family 0x0004 Accessible only by type and sub-types
> FamORAssem 0x0005 Accessibly by sub-types anywhere, plus anyone in
> Public 0x0006 Accessibly by anyone who has visibility to this scope field
> contract attributes
> Also this may be of interest
> 22.214.171.124.2 Controlled-mutability managed pointers
> The readonly. prefix and unbox instructions can produce what is called a
> controlled-mutability managed pointer. Unlike ordinary managed pointer
> types, a controlled-mutability managed pointer is incompatible with ordinary
> managed pointers; e.g., it cannot be passed as a byref argument to a method.
> At control flow points, a controlled-mutability managed pointer can be
> merged with a managed pointer of the same type to yield a
> controlled-mutability managed pointer.
> Controlled-mutability managed pointers can only be used in the following
> 1. As the object parameter for an ldfld, ldflda, stfld, call, callvirt,
> or constrained. callvirt instruction.
> 2. As the pointer parameter to a ldind.* or ldobj instruction.
> 3. As the source parameter to a cpobj instruction.
> All other operations (including stobj, stind.*, initobj, and mkrefany) are
> The pointer is called a controlled-mutability managed pointer because the
> defining type decides whether the value can be mutated. For value classes
> that expose no public fields or methods that update the value in place, the
> pointer is read-only (hence the name of the prefix). In particular, the
> classes representing primitive types (such as System.Int32) do not expose
> mutators and thus are read-only.
>> -----Original Message-----
>> From: bitc-dev-bounces at coyotos.org [mailto:bitc-dev-
>> bounces at coyotos.org] On Behalf Of Sandro Magi
>> Sent: Thursday, March 24, 2011 10:42 PM
>> To: Discussions about the BitC language
>> Subject: Re: [bitc-dev] Inner references, regions, and CLI
>> On 24/03/2011 10:33 AM, Sandro Magi wrote:
>>> The problem with your solution is that I don't think it's CLI safe
>>> unless the VM is running under "full trust". I believe the VM will
>>> prevent you from accessing the private fields of another object since
>>> this code is not verifiable (unless all fields are public?).
>> Your only solution here is to mark these fields "internal", and any fields
>> may be captured as a ref provide an InnerReference overload bundled with
>> the assembly. This is in the safe subset.
>> Then again if you're doing this analysis already you have enough
>> for my solution, which is probably more efficient, ie.
>> indirect memory references for ML refs are probably more efficient than
>> branch mispredicts due to virtual dispatch.
>> bitc-dev mailing list
>> bitc-dev at coyotos.org
> bitc-dev mailing list
> bitc-dev at coyotos.org
More information about the bitc-dev