[pro] Heartbleed?

[Pascal J. Bourguignon]

"Scott L. Burson" <Scott at sympoiesis.com> writes:

> On Thu, Apr 24, 2014 at 7:29 PM, Steve Haflich <shaflich at gmail.com> wrote:
>> Take for example aref, which might be used to
>> extract octets of characters or whatever from a buffer.  aref makes no
>> guarantees even in safe code that it will signal bad array bounds.
>
> I've long thought that was an oversight, though now that you point it
> out, I realize I must have been mistaken.
>
> Still, it surprises me.  I don't know of any implementation that
> doesn't bounds-check aref under normal speed/safety settings, and
> clearly, users expect them to do so.  It seems a little pedantic to
> insist that the _language_ isn't safe in this respect even when all
> known implementations are.  (Am I wrong about that?)

The point is that ANSI Common Lisp compiler writers will have their
compilers generate run-time bound checking code, while ANSI C compiler
writters won't.

The point is that ANSI Common Lisp compiler writers will add extensions
to the language or "standard library" to deal with sockets and network
communications, while ANSI C compiler writers won't (relaying on library
and OS API writers to do so).

The point is that ANSI Common Lisp compiler writers don't need to add
exception handling as an extension because it's already specified in the
language, while ANSI C compiler writers would have to do so, to deal
non-trivially with run-time errors.

> And for the record I disagree with the committee's decision.  Bounds
> checking aref etc. _should_ be required at safety 3 (and along with
> that, there should be a standardized bounds-error condition type).
> The reasoning behind the committee's choice here eludes me.

Agreed, a programming language standard should not rely on the good
sense of implementers to ensure the semantics of its programs, the more
so in a dynamic language where code can be executed without being
previously globally validated.


But again, AIUI, Common Lisp was specified as much as it was documenting
the commonality in existing implementations, so that may explain why
there are so many parts that are unspecified or implementation dependant.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"