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

Sandro Magi naasking at higherlogics.com
Thu Apr 8 23:05:02 PDT 2010

On 09/04/2010 12:24 AM, Mike Samuel wrote:
> "A programmer using this language then expects that an array can be
> changed only by using the update operation on it explicitly---and not,
> for example, by writing past the end of some other data structure.
> Similarly, one expects that lexically scoped variables can be accessed
> only from within their scopes, that the call stack truly behaves like a
> stack, etc."
> Pierce clearly considers unexpected results an abstraction violation.

Not how you're using "unexpected results". If you take it to mean
"results inconsistent with the safety properties guaranteed by the
spec", then I agree, and in fact Java implements exactly these safety
properties and thus is safe.

You're using "unexpected results" to mean, "behaviour that someone
unfamiliar with the spec disagrees with or does not understand".

> And the case of arrays is not a case of one abstraction violating
> another without any "abstraction boundary" violation -- only one
> abstraction, arrays, need be involved in an out of bounds pointer
> dereference.

I assume you're referring to my C example. Local variables are indeed a
completely separate abstraction from arrays, and yet you can set a local
variable by setting an array slot. How is that not a case of one
abstraction violating another?

> Floating point in java violates expectations.

Violating expectations is not a safety property, unless said
expectations are explicitly specified as properties guaranteed by the
spec. Non-strictfp code guarantees fewer properties than strictfp code,
but is not inherently unsafe.

> One reasonably expects that
>     double[] arr = new double[100000];
>     for (int i = arr.length; --i >= 0;) { arr = 12345678d / 87654321d; }
> Programmers reasonably expect that floating point operations within a
> platform are reproducible, but that is not the case when the JIT can
> kick in at an arbitrary point and start using 80b registers where 64b
> registers were used earlier in a loop.

Assuming that can actually happen in the middle of a loop, then the
property "Programmers reasonably expect that floating point operations
within a platform are reproducible" is simply false for non-strictfp
Java. In other words, an abstraction that you WANT is being violated,
not an abstraction that Java PROVIDES. Big difference.

What Java provides is a perfectly valid semantics for non-portable
floating point code, and no abstraction is actually being violated. The
absence of your property for non-strictfp code does not make Java
unsafe, because determinism is not a property of Java. In order for you
to demonstrate a safety violation, this semantics must contradict some
other property guaranteed by the spec.

If strictfp were specified and the 80b ops were used, THEN the floating
point abstraction would be violated. If the Java spec guaranteed
determinism for all value operations, THEN abstraction would be
violated. As far as I can see, the floating point semantics are
perfectly consistent and safe, albeit not very programmer friendly in
non-stricfp mode.


More information about the cap-talk mailing list