[cap-talk] definition of the term "safe language"

Ben Kloosterman bklooste at gmail.com
Wed Apr 7 20:53:23 PDT 2010


>
 >As such, there is a range of unsafeness -- some unsafe languages may
 >have some inviolable abstractions like memory, and some violable ones,
 >such as the repeatability of floating point operations.  Java is
 >arguably an example of just such a language because of the
 >unpredictability of the use of 80b floats, the code
 >   double[] arr = new double[100000];
 >   for (int i = arr.length; --i >= 0;) { arr = 12345678d / 87654321d; }
 >might not fill the entire array with the same value.  But the failure
 >of this abstraction does not break memory safety.
 >Java used to be unsafe around doubles and long fields of objects
 >assigned by multiple threads.
 
There are many cases where the language is safe but the runtime or sandbox specification or implementation makes using the language unsafe. IMHO the language is the trivial case the ones you mentioned are perfect examples there is nothing wrong with the language there but the way the runtime executes it. I would rather have a language and runtime that’s almost safe  than the more common case where the language is safe but the run time has issues. And in fact a runtime could even make a non precompiled unsafe language safe by disallowing certain actions though you could argue it’s a different language. A good example is C# if you allow Full trust ( or /unsafe) it cannot be safe since this allows reflection ( ie self modifying CIL code) though the language itself is safe.





More information about the cap-talk mailing list