"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 "internal" [1].
Sandro [1] http://msdn.microsoft.com/en-us/library/7c5ka91b.aspx 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 > 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 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
