[bitc-dev] Inner references, regions, and CLI

[Sandro Magi]

"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: 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
> 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
>> bitc-dev at coyotos.org
>> http://www.coyotos.org/mailman/listinfo/bitc-dev
> 
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev