Hi Pascal
That was very funny! Heh!
But in case you weren't trying to be funny, then I'd have a guess that you were born sometime later than 1970 or so.
Everything happens in an historical context. And if the C language had raised exceptions on "invalid" memory accesses, then I can assure you that neither I nor anyone else at the time would have used such a language. It would have been too constraining. If you wanted such confining behavior then you might have considered the new language Ada.
I'd love to discuss at greater length but right now I'm attending a Chamber Concert and not near my computers.
From what I understand about the bug (I have not seen the code) it sounds like data length information arrived both directly and indirectly in the client message and that a conflict between them was not scrutinized.
More later...
Dr. David McClain
Sent from a mobile device
On Apr 13, 2014, at 3:01, "Pascal J. Bourguignon" pjb@informatimago.com wrote:
David McClain dbm@refined-audiometrics.com writes:
Just curious for other opinions... but wouldn't this (Heartbleed) sort of buffer excess read-back failure have been prevented by utilizing a "safe" language like Lisp or SML?
I used to be an "unsafe" language bigot -- having mastered C/C++ for many years, and actually producing C compilers for a living at one time. I felt there should be no barriers to me as master of my machine, and not the other way around.
Oh, so you are directly (if partially) responsible for the C mess!
The C standards say that:
{ char a[10]; return a[12]; }
is _undefined_.
Why, as a compiler writer, didn't you define it to raise an exception? Yes, the C standard doesn't define exceptions, why, as a compiler writer, didn't you add this obvious extension?
Notice how CLHS aref specifies:
subscripts---a list of valid array indices for the array.
Exceptional Situations: None.
and how:
1.4.4.3 The ``Arguments and Values'' Section of a Dictionary Entry
An English language description of what arguments the operator accepts and what values it returns, including information about defaults for parameters corresponding to omittable arguments (such as optional parameters and keyword parameters). For special operators and macros, their arguments are not evaluated unless it is explicitly stated in their descriptions that they are evaluated.
Except as explicitly specified otherwise, the consequences are undefined if these type restrictions are violated.
Which means that (let ((a (make-array 10))) (aref a 12)) is as undefined in CL as in C!
However, you don't see Lisp implementers allow it, and instead they all signal an error:
[pjb@kuiper :0.0 tmp]$ clall -r '(let ((a (make-array 10))) (aref a 12))'
Armed Bear Common Lisp Invalid array index 12 for #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL) (should be >= 0 and < 10). Clozure Common Lisp Array index 12 out of bounds for #(0 0 0 0 0 0 0 0 0 0) . CLISP AREF: index 12 for #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL) is out of range CMU Common Lisp Error in function LISP::%ARRAY-ROW-MAJOR-INDEX: Invalid index 12 in #(0 0 0 0 0 0 0 0 0 0)