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 assembly Public 0x0006 Accessibly by anyone who has visibility to this scope field contract attributes
Also this may be of interest 1.8.1.2.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 ways: 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 invalid. 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. Ben > -----Original Message----- > From: [email protected] [mailto:bitc-dev- > [email protected]] 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 that > 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 information > 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. > > Sandro > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
