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

[Mike Samuel]

2010/4/8 Sandro Magi <naasking at higherlogics.com>:
> On 08/04/2010 5:41 PM, Mike Samuel wrote:
>>> This was an intentional decision to provide an alternate semantics to
>>> floating point [1]. Differing semantics does not imply a safety violation.
>>
>> Yes.  And a reasonable decision.  But that is beside the point.
>>
>> C made a quite intentional decision to not be a memory safe language.
>> That a language has an intentionally weak abstraction does not make
>> the language safe according to the definition in the original post.
>
> I think you're misunderstanding the definition. Safety is not synonymous
> with the portability of abstractions, which seems to be what you're
> implying. There are safe assembly languages for instance.

I was not talking about portability at all, and I think you're
misunderstanding the definition.

"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.
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.

Floating point in java violates expectations.
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.


> The reason C is not safe is that the array abstraction can arbitrarily
> influence other abstractions, like structures or locals. Abstraction
> boundaries are not enforced.
>
> The non-portability of Java's floating point operations do not escape
> the floating point domain, and certainly do not influence other
> abstractions like object field values. Abstraction boundaries in Java
> are enforced.
>
> The particular semantics of an abstraction, portability included, are
> irrelevant to safety. Unless of course the language specification
> explicitly requires portability as a safety property. The optional
> strictfp keyword indicates that Java clearly does not require this
> safety property.
>
> Sandro
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>