A.L. <a...@z...com> napisał(a):
> Chodzilo mi o sugestie oryginalnego pytacza jakoby poprawnosc programu
> mozna bylo sprawdzic na etapie kompilacji, otrzymujac gwarancje ze
> program nie naruszy pewnych ograniczen (pamiec itede) ktorych potem w
> trakcie wykonywania sprawdzac nie trzeba.
> Moje "nie da sie" dotyczylo takiego sprawdzania i posiadania takiej
> pewnosci
> A.L.

Pan z Microsoftu ma dosyć dużą pewność:
Before the code is run, the IL is compiled into native executable code. And,
since this compilation happens by the managed execution environment (or,
more correctly, by a runtime-aware compiler that knows how to target the
managed execution environment), the managed execution environment can make
guarantees about what the code is going to do. It can insert traps and
appropriate garbage collection hooks, exception handling, type safety, array
bounds and index checking, and so forth. For example, such a compiler makes
sure to lay out stack frames and everything just right so that the garbage
collector can run in the background on a separate thread, constantly walking
the active call stack, finding all the roots, chasing down all the live
objects. In addition because the IL has a notion of type safety the
execution engine will maintain the guarantee of type safety eliminating a
whole class of programming mistakes that often lead to security holes.
http://blogs.msdn.com/brada/archive/2004/01/09/48925
.aspx

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i aktualności ze świata Outlook Express: grzegorz.net/oe
Uptime: 27 days, 1 hours, 51 minutes and 8 seconds