[pro] Heartbleed?

[David McClain]

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 at informatimago.com> wrote:
> 
> David McClain <dbm at 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 at 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)