Compilers

[fw at deneb.enyo.de (Florian Weimer)]

* Crispin Cowan:

> > > I'm with you on the C and C++ argument, but what is immature about Java?
> > > I thought Java was a huge step forward, because for the first time, a
> > > statically typesafe language was widely popular.
> > >     
> > Java is not statically typesafe, see the beloved ArrayStoreException
> > (and other cases, depending what you mean by "statically typesafe").
> >   
> So every language that supports arrays is not statically type safe?

No, the Java case is a bit peculiar because of the array subtyping
rules.  If B extends A, a B[] is also an A[], but you cannot actually
store As into such an A[].  This is enforced by a run-time check
(which raises ArrayStoreException, which is not triggered by an
out-of-bounds array access), and I think it means that Java is not
statically typesafe by any reasonable definition (or, at least, its
arrays aren't).

> What language does better on array bounds typing?

This wasn't my point, but: There has been some work in this area
(particularly in respect dependent types), IIRC.  But such type
systems tend to be undecidable in general, and type inference is both
a must and pretty difficult.

I'm not sure if this is a significant issue as far as secure coding is
concerned because in many systems, you can restrict the code which
relies heavily on bounds checking (typically some sort of parser) to a
module, and if a failure occurs, you discard the PDU that trigger it.
The parser itself can be constructed using a statically verifiable
domain-specific language, or if the protocol is rather baroque, using
tools like SPARK, to minimize PDU drops due to coding errors.

And in the case of Java, null pointer exceptions seem to be a far
greater threat to reliability than array bounds checks.