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).

On Wed, Apr 23, 2014 at 11:39 AM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>
>
> and ask you to implement it only using the CL package, you won't be able
> to implement it in any CL implementation using non-zero safety, and you
> won't be able to implement it in most CL implementations using (safety 0).


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.)
 
> This you could easily implement in CL, (as easily as in C), but again,
> while in C this is a heartbleed bug, in CL, it poses absolutely no
> security problem (unless you're using some certain implementations with
> (safety 0), which you should not have done anyways, you're really asking
> for problems, aren't you).

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.

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.

(But I certainly agree that the Heatbleed bug results from a poor implementation of an obscure specification.  But it isn't the language.)
 
> So it's not just the specifications, it's the language implementations
> that are at fault here (not the ANSI C language, which clearly says that
> it's undefined to read an uninitialized array or outside of allocated
> memory, and therefore you could expect as with any CL implementation to
> have exceptions signaled in such occurences (since it's undefined,
> implementation could define implementation specific exception
> mechanisms)).

"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.

(funcall (compile nil