Thanks for the pointer. Reflection doesn't concern me - it's in a position to rewrite the binary arbitrarily, and it's a horrendous security hole.
shap On Thu, Mar 11, 2010 at 6:19 AM, Sandro Magi <[email protected]>wrote: > This is another well-known failure of full abstraction between C# and > the CLI [1]. Under full trust, bytecode can arbitrarily set read-only > fields, as can reflection. > > Sandro > > [1] Section "Use Read-only Properties Appropriately", > > http://msdn.microsoft.com/en-us/library/aa480477.aspx#pagguidelines0003_class6 > > On 10/03/2010 11:54 PM, Jonathan S. Shapiro wrote: > > On Wed, Mar 10, 2010 at 8:20 PM, Sandro Magi <[email protected] > > <mailto:[email protected]>> wrote: > > > > The CLR's notion of read-only field is rather useless as it's only > > enforced when running in medium trust mode. At least for the > > MS.NET<http://ms.net/> > > <http://ms.net/> > > implementation. > > > > > > I don't know enough about what happens at the CLR level to have an > > opinion about that. At the C# level, the problem is that read-only goes > > into effect at the end of the constructor call, but the "this" pointer > > can escape beforehand. This can effectively reveal the field before the > > moment of initialization. > > > > shap > > > > > > > > _______________________________________________ > > 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
