<div dir="ltr">There have been a lot of incorrect information and assumption on this thread. Â I'm not picking on Pascal here (because I know he knows better).<br><br>On Wed, Apr 23, 2014 at 11:39 AM, Pascal J. Bourguignon <<a href="mailto:pjb@informatimago.com">pjb@informatimago.com</a>> wrote:<br>
><br>><br>> and ask you to implement it only using the CL package, you won't be able<br>> to implement it in any CL implementation using non-zero safety, and you<br>> won't be able to implement it in most CL implementations using (safety 0).<br>
<br><br>In any case, you won't be able to implement an HTTP server in ANSI CL because we of X3J13 didn't get around to defining any socket interface. Â It was a known need, but too difficult to achieve. Â That's probably a good thing, because any standard socket binding circa 1990 would likely have been seriously incorrect and/or inadequate. Â (Compare the lack of Unicode binding.)<br>
 <br>> This you could easily implement in CL, (as easily as in C), but again,<br>> while in C this is a heartbleed bug, in CL, it poses absolutely no<br>> security problem (unless you're using some certain implementations with<br>
> (safety 0), which you should not have done anyways, you're really asking<br>> for problems, aren't you).<br><br>You're making unsupported assumptions about safety 0. Â The ANS only makes distinction between safety _3_ and safety anything else. Â safety 3 is safe code and in safe code certain user-code violations are required to be signalled (usually where the ANS uses the word "should"). Â And there are damn few of thos places. Â 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.<br>
<br>Of course, it is unlikely that a HTTP server would use aref in this context, but more likely it would engage implementation-dependent socket and/or stream extensions. Â Do those extensions guarantee the kind of paranoid safe checking? Â Probably not, but even if they claim to do so, how does one verify? Â Real socket protocols use large buffers and simply pass memory pointers and lengths AT the OS. Â You might think that is bad practice, but you might dislike the performance in a _real_ performance web server that made too many guarantees.<br>
<br>(But I certainly agree that the Heatbleed bug results from a poor implementation of an obscure specification. Â But it isn't the language.)<br>Â <br>> So it's not just the specifications, it's the language implementations<br>
> that are at fault here (not the ANSI C language, which clearly says that<br>> it's undefined to read an uninitialized array or outside of allocated<br>> memory, and therefore you could expect as with any CL implementation to<br>
> have exceptions signaled in such occurences (since it's undefined,<br>> implementation could define implementation specific exception<br>> mechanisms)).<br><br>"Consequences are undefined" ïs a term of art in the ANS.  Behavior might range from DWIM to destruction of the Universe. You cannot expect a CL implementation to check situations that are not specified by the ANS to be checked.  I just checked the following form in SBCL and ACL -- both did undefined things and did not signal errors.<br>
<br><font face="courier new, monospace">(funcall (compile nil</font><div><font face="courier new, monospace">Â Â Â Â Â Â '(lambda (x)<br>Â Â Â Â Â Â Â (declare (optimize (speed 3) (safety 0)))<br>Â Â Â Â Â Â Â (svref x 10)))<br>
     (make-array 3))</font><br><br></div><div>Just like C, but at least the Universe didn't disappear.  This time.</div><div><br></div><div>CL is not intrinsically more safe than C  How any favorite implementation behaves is irrelevant to this argument.  It is the programmer that must code safely.</div>
<div>.</div></div>