> cfmd@swipnet.se (Magnus Danielson) wrote on 01.01.00 in <20000101023746F.cfmd@swipnet.se>:
>
> > Oh yes... like those that those who avoid strcpy by doing
> >
> > memcpy(t, s, strlen(s)+1)
> >
> > I mean, memcpy is supposed to be safe, ain't it ;)
>
> I guess what we _really_ need is some sort of super lint. That is, a
> program that can analyze C code (others are fine, but C is the most
> important by far) and highlights problematic points in the code.
>
> And then there should be some sort of pseudo-comment which you can use to
> explain properties of, say, pointed-to data, to possibly allow the super
> lint to find out that the code is safe after all - except that somewhere
> else, you violated those properties.
>
> Note that this is NOT full program proof, which is far harder to get
> right. You only want to prove that you don't overrun buffers and (while
> we're at it) that you don't use unchecked data in critical places (what
> Perl taint checking tests).
>
> This would not mean that your program actually does anything useful, only
> that it's safe against some kinds of attack.
>
> And it would have zero runtime overhead.
Unfortunately, your approach was proved impossible well before the
transistor was invented. See "halting problem".
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/