>I suppose referents from other assemblies shouldn't be permitted access to field f (correct me if I'm wrong).
Right
>However, according to section 8.5.3, access is permitted since:
>- class Inner is visible (nested types have the same visibility as their enclosing type!)
>- field f is accessible
Inner is visible, but not accessible. Therefore Inner and all its
members (including f) can't be accessed from other assemblies.
>And what if a referent is granted access to field f, but not to type Foo?
You can't have members that are more accessible than their type, that
would give you a compile error.
Mattias

Signature
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
pn - 10 Feb 2004 09:36 GMT
>Inner is visible, but not accessible. Therefore Inner and all it
>members (including f) can't be accessed from other assemblies
I realize that's true for C# programs, but is it enforced by the CLR? And if so, isn't there something wrong with the definitions in the CLI Standard, section 8.5.3
>You can't have members that are more accessible than their type, tha
>would give you a compile error
Compile error? You mean the MSIL assembler? Mind you, I'm not talking about C# programs (everything is clear there). But doesn't the CLR have to handle these issues as well? What if I write an "evil" MSIL program
Mattias Sj?gren - 12 Feb 2004 16:16 GMT
>I realize that's true for C# programs, but is it enforced by the CLR?
Yes
>And if so, isn't there something wrong with the definitions in the CLI Standard, section 8.5.3 ?
What's wrong with it?
>Compile error? You mean the MSIL assembler? Mind you, I'm not talking about C# programs (everything is clear there).
No, I meant the C# compiler. ILASM will let you write all sorts of
invalid or unusable metadata, that may or may not load at runtime.
>What if I write an "evil" MSIL program?
That does what exactly?
Mattias

Signature
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
pn - 24 Feb 2004 14:01 GMT
>>And if so, isn't there something wrong with the definitions in the CLI Standard, section 8.5.3
>What's wrong with it
According to the definitions, access to field f IS granted (see my first posting). As far as I understand, this part of the specification is flawed and incomplete
Regards
pn
Fabian Schmied - 26 Feb 2004 19:36 GMT
> According to the definitions, access to field f IS granted (see my
> first posting). As far as I understand, this part of the
> specification is flawed and incomplete.
As I see it, access to field f is not granted.
8.5.3 says "Access to a member of a type is permitted only if all three
of the following conditions are met:
1. The type is visible.
2. The member is accessible.
3. All relevant security demands (see clause 8.5.3.3) have been granted."
Back to your example:
public class Outer {
internal class Inner {
public Foo f;
}
}
Let's check the visibility.
8.5.3.1: "Nested within another type. In this case, the type itself has
the visibility of the type inside of
which it is nested (its enclosing type)"
So, you are right: Inner has the same visibility as Outer. f is public,
its type is visible, ignoring security demands, it would be accessible
according to 8.5.3.
However, check the accessibility of Inner. The important thing is that
Inner is treated like a member here, this is mentioned in 8.5.3.4:
"A nested type has the same visibility as the
enclosing type and has an accessibility as would any other member of the
enclosing type. This accessibility
determines which other types may make references to the nested type."
So, although access to f seems to be granted, its containing type cannot
be referenced. When you cannot reference the type, you cannot reference
the field.
That's how I see it.
Fabian
pn - 27 Feb 2004 09:01 GMT
Thanks for your input. Seems I didn't read clause 8.5.3.4 carefully enough. Still I think that clause 8.5.3.1 should be more explicit, but that's not such a big issue
I wonder why the CTS distinguishes visibility (for top-level types) and accessibility (for type members, including nested types). I believe that one unified concept of accessibility (as in C#) would simplify matters. Maybe I'll turn that into a new question to the forum. :-
Regards
pn