Hey Sebastien, Thanks for all the info. > That would be wrong, but you're right that icalls are a bit special. > The main point is detect-sc cannot generalize them, like p/invokes can > be. > <snip> > Here a counter-example (Math.cs) why: > > [MethodImplAttribute (MethodImplOptions.InternalCall)] > public extern static double Floor (double d); Do I summarize correctly if I say that there are icalls that can do no harm, and icalls that can, so we cannot just mark them as SecurityCritical. (because of the ones that can do no harm like Math.Floor). ?
Wouldn't it be easier from an audit perspective if all icalls are by default considered SecurityCritical, unless manually specified [Transparent] (like for Math.Floor). Maybe it's a bit annoying adding those attributes manually, however, it also seems like quite a error prone taks to take all icalls that can do harm, and make sure that they're really really only being called from securitycritical code. (now, and in the future) Bye, Lucas _______________________________________________ Moonlight-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/moonlight-list
