<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>Jay I deliberately want to quote you this text for your better understanding [1] (I hope it to be so):<br>"...<br>Software Security Explained<br>The concepts behind secure software are often simple but rarely considered by most programmers in the design and implementation of their programs.<br>The following are prime tenets in writing secure software:<br>Give your software the least privileges it needs.<br>Check all return codes religiously.<br>..."<br><br>http://books.google.com.co/books?id=uGiOR1mrxggC&dq=inauthor%3A%22Jeff+Schmidt%22&q=%22software+security%22#search_anchor<br><br>And specifically for ther matter of "assumptions" and pointer initialization:<br><br>http://www.drdobbs.com/security/safe-programming-with-modula-3/184408858<br><br>note that if you guarantee "assumptions" or " absence of unchecked run-time errors" you can argue
that still you export the interface as safe. in SPwM3 [2] p.45<br><br>"...<br>2.5.7 Safety<br>...<br>An interface is 'intrinsically safe' if there is no way to produce an unchecked runtime error by using the interface in a safe module.<br>..."<br><br>Now if you say, the VAX9000 or Alpha had probably errors more than any other computer in the era, it could mean that the VAX9000 or Alpha had runtime unchecked errors (probably by that much as any other but let's read this $1.4.5 Safety paragraph) : SPwM3 p. 7<br>"...<br> 1.4.5 Safety<br> ...<br>Unfortunately, it is generally impossible to program the lowest levels of a system with complete safety. Neither the compiler nor the runtime system can check the validity of a bus address for an I/O controller, nor can they limit the ensuing havoc if it is invalid. This presents the language designer with a dilemma. Of he holds out for safety, then low level code will have to be programmed in another
language. But if he adopts unsafe features his safety guarantee becomes void everywhere<br>..."<br><br>Now, in every definition of safety of a language there must be the unchecked runtime errors (errors than can occur without isolation guarantee), you must define them explicitly as a subset of all untrapped errors. I think one of them is the mentioned above, if we could agree on this errors by platform we can say our language implementation is safe in this proportions due machine restrictions. In case of VAX9000 architecture segments were defined for separated testing of multichip Modules, you could argue you can still work in a isolated machine and guarantee each piece of Hardware satisfies certain properties, so you could think in a top-down fashion how would you build and test your machine for errors that are HW failures and in some cases avoid running the program in those conditions by using fault tolerance.<br>There was a VAXft9000 and Alpha's
versions of itself, of course this costs lot more to work in that way, so in general you can't do that as SPwM3 says, but if you want we can do it.<br><br>Thanks in advance<br><br>[1] J. Schmidt, Microsoft Windows 2000 security handbook. Que, 2000.<br>[2] C. G. Nelson, Systems programming with Modula-3. Prentice Hall, 1991.<br><br>--- El <b>lun, 4/2/13, Jay K <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Jay K <jay.krell@cornell.edu><br>Asunto: [M3devel] Socket error hacks for Ultrix and OSF?<br>Para: "m3devel" <m3devel@elegosoft.com><br>Fecha: lunes, 4 de febrero, 2013 02:14<br><br><div id="yiv1585318794">
<style><!--
#yiv1585318794 .yiv1585318794hmmessage P
{
margin:0px;padding:0px;}
#yiv1585318794 body.yiv1585318794hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style><div><div dir="ltr">We have:<br><br> WITH errno = GetError() DO<br> IF errno = EINVAL THEN<br> (* hack to try to get real errno, hidden due to NBIO bug in connect *)<br> RefetchError (t.fd);<br> ELSIF errno = EBADF THEN<br> (* we'll try the same for EBADF, which we've seen on Alpha *)<br> RefetchError (t.fd);<br> END;<br> END;<br><br><br>PROCEDURE RefetchError(fd: INTEGER) =<br>(* Awful hack to retrieve a meaningful error from a TCP accept<br> socket. Only works on Ultrix and OSF. Leaves result<br> in
GetError(). *)<br> VAR optbuf: int := 0; optlen: socklen_t := BYTESIZE(optbuf);<br> BEGIN<br> IF SocketPosix_IsUltrixOrOSF.Value THEN<br> EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY,<br> ADR(optbuf), ADR(optlen));<br> END;<br> END RefetchError;<br><br><br>does anyone know or believe this is useful code?<br>Does anyone object to removing it?<br>I don't believe we'll ever run on Ultrix.<br>OSF/Tru64 is of very marginal interest.<br>Posix doesn't bless this code.<br>It seems ok without this -- it is a subtle matter of precisely which error is raised.<br>Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more
specific.<br>If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look.<br><br><br><br>More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6...<br><br><br> - Jay<br><br><br> </div></div>
</div></blockquote></td></tr></table>