<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 10:35 PM, Jean-Claude Beaudoin <span dir="ltr"><<a href="mailto:jean.claude.beaudoin@gmail.com" target="_blank">jean.claude.beaudoin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="">On Fri, Apr 25, 2014 at 12:31 AM, Scott L. Burson <span dir="ltr"><<a href="mailto:Scott@sympoiesis.com" target="_blank">Scott@sympoiesis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>I've long thought that was an oversight, though now that you point it<br>
out, I realize I must have been mistaken.<br></blockquote></div></div></div></div></blockquote><div><br></div><div>"Oversight" might be the wrong way of thinking about this. X3J13 started with the language defined by CLtL1 (the work of the infamous Gang of Five) with the purpose of turning it into a powerful, useful, real-world industrial-strength programming language. Except for new subsystems grabbed more-or-less intact from other sources (Waters' pretty printer, the condition system (Pitman and others), and CLOS (a different gang inside X3J13)) the specification started with the CLtL1 definitions to which cleanups and accretions were made. There were a lot of inconsistencies to remove, and a lot of language cleanups, and a lot of incompatibilities as modern features were added. But a lot of culture from early era Lisps (primarily MACSYMA) remain. We changed what _needed_ to be changed, cleaned up a lot of other inelegances, but there was not time or energy to attempt a thorough job. The subgroups for things like graphics and I18N and networking realized the time was not yet ripe -- the world was changing out from under them -- and the committee The process took almost 6 years, and near the end time and funding was running out. Eventually the committee standardized _only_ the programming language, more or less, and we were lucky to get it done.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Still, it surprises me. I don't know of any implementation that<br>
doesn't bounds-check aref under normal speed/safety settings, and<br>
clearly, users expect them to do so. <br></blockquote><div><br></div></div><div>I am surprised too. I always understood it like you Scott but now that re-read<br></div><div>the page on aref I see that it is exactly like Steve says, no mention of any<br>
</div><div>exception and a statement that "subscripts" must be a list of valid array indices<br></div><div>right from the start of the call to aref. Yet that leaves me even more curious<br></div><div>to know which implementation has read the spec as strictly as Steve says<br>
</div><div>it can be even under (safety 3)? Does anyone know any?</div></div></div></div></blockquote><div><br></div><div>I don't know of any and there might not be any, at least among main-line implementations. I don't remember X3J13 considering aref (except for the non-interaction with a fill pointer) but I also can't remember what I had for breakfast this morning, so investigation of X3J13 records might reveal differently. The lack of exhaustive subtyping of cl:error was recognized as something missing, but the condition system itself wasn't in the original language, and no one had the time or energy to go through the entire specification. The sense was that a quality implementation could do so itself, and maybe agre on details in the future.</div>
<div><br></div><div>But in your paragraph above I'm bothered by its hidden assumption: It suggests that after the ANS was available sneaky implementors studied it kabalistically to find places where annoying error checks could be removed. It was exactly the opposite! Tired implementors slogged through the ANS to find places where error checking was _required_ and found missing. (Or customers did it for them.)</div>
<div><br></div><div>I agree it would be a good thing if the ANS required aref bounds checking in safe code.</div><div><br></div><div>To return to my important point, the language of the ANS wont let you read or write from a socket. At some point user application code will have to call some non-ANS functions, and in the real world those functions (just like C) will take a pointer into some overlarge buffer array along with a length, and that memory location will be passed further down to some system code (likely written in C) that has access to the entire user-space memory. Now, without the missing check on the length that allowed the Heartbleed bug, such an error won't allow buffer overruns in either input or output, but my point is that user C code and user CL code are little different in this regard.</div>
<div><br></div></div></div></div>