tag:blogger.com,1999:blog-14427379.post112836715038508891..comments2023-05-30T15:20:21.068+02:00Comments on The Core Dump of Thought: Secure programmingzvrbahttp://www.blogger.com/profile/08806965334872601252noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-14427379.post-1128944734618520602005-10-10T13:45:00.000+02:002005-10-10T13:45:00.000+02:00Once thing you're overlooking is that it's wrong t...Once thing you're overlooking is that it's wrong to contrast C (and C++) as "unsafe" languages to Python, Perl, Ruby, Lisp, and such as "safe" ones. While these other languages are more impervious to typical programmer fuckups, such as writing past the end of a simple array, they too make it possible to write invalid (as well as incorrect) code. Of all the mentioned alternatives to C, I believe only Java actually aims to make it <I>impossible</I> to write invalid code, at least as long as you stick to 100% Java.<BR/><BR/>For example, in Lisp, it is undefined behavior to modify a constant list, such as created with (let ((foo '(a b c))) ...). In both Python and Perl you can <I>very</I> easily attain invalid code, typically by incorrectly using a "thin" interface to a native facility. Another way is by pushing the interpreters to their limit, for example by abusing infinite recursion. Or by encountering implementation deficiencies, such as regexp engine coredumps with large regexps. (The "toy" languages such as Perl and Python typically have most of their low-level functionality implemented in C to make up for their atrocious execution; this makes their internals susceptible to exactly the kind of bugs any other large C program faces. Lisp and Java at least have real native code compilers which remove the necessity for their innards containing large chunks of unsafe C code.)<BR/><BR/>Invalid code is a possibility in all languages (except in 100% Java, barring JVM bugs), it's just that C and C++ make it easy to screw up while doing things that should really be easy -- like accessing arrays.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14427379.post-1128691489276769632005-10-07T15:24:00.000+02:002005-10-07T15:24:00.000+02:00So, how do you think a computer could identify a c...So, how do you think a computer could identify a certain piece of code as e.g. a sorting routine?<BR/><BR/>As for unit testing: while it is certainly useful, it is not a way of <I>proving</I> that something is correct. The fact that a piece of software works for N inputs, doesn't guarantee that it will work for <I>all possible</I> inputs. Unless your N test cases really <I>do</I> exhaust the domain of your problem.<BR/><BR/>Even if the domain of your problem is sufficiently small that it can be exhaustively tested, you are still left with a (in the general case,<I>infinite</I>) number of <I>invalid</I> inputs that should also be properly handled.<BR/><BR/>In the end, who is supposed to debug the unit tests? :)zvrbahttps://www.blogger.com/profile/08806965334872601252noreply@blogger.comtag:blogger.com,1999:blog-14427379.post-1128676136338109372005-10-07T11:08:00.000+02:002005-10-07T11:08:00.000+02:00Interesting ideas, but I wonder why you think it i...Interesting ideas, but I wonder why you think it is so difficult to discover a programmer's intentions - surely these can be automatically discovered from a test suite ?<BR/><BR/>Granted, there may be no test suite, and then we are back to AI, but that is just a reason to insist on unit testing.<BR/><BR/>OTOH - if there is no test suite then I would despair of any AI being able to discover intentions. I've been a devloper and a teacher for decades, and I would find it hard to determine intentions from pure code - I don't think any AI is going to be doing it soon ;-)Alanhttps://www.blogger.com/profile/04461864767711064154noreply@blogger.com