WANTED: ISPs with DDoS defense solutions
Jack Bates
jbates at brightok.net
Sat Aug 2 01:19:33 UTC 2003
Vadim Antonov wrote:
> Lack of real strong typing, built-in var-size strings (so the compiler can
> actually optimize string ops) and uncontrollable pointer operations is
> enough to guarantee that any complicated program will have buffer-overflow
> vulnerabilities.
Typing can be enforced if the programmer chooses to.
> So does assembler - way more than C.
I agree. I love both.
> Presumeably, a non-idiot can produce ideal code in significant
> quantities. May I politely inquire if you ever wrote anything bigger than
> 10k lines - because anyone who did knows for sure that no program is
Of course, and yes.
> ideal, and that humans forget, make mistakes and cannot hold the entire
> project in mind, and that our minds tend to see how things are supposed to
> be, not how they are - making overlooking silly mistakes a certainity.
Correct. It cannot be held in mind, which is why a model must be
fashioned and enforced so that the programmer minimizes mistakes. There
are many tools available to help one do this, and it's not too difficult
to write your own. In some cases, it's common sense.
> C is a workable language, but it is not close (by far) to a language which
> would incorporate support for known best practices for large-scale
> software engineering. C++ is somewhat better, but it fails horribly in
How do you figure? Best Practices is what you do with what you have, not
what you have itself. Ingress/Egress filtering is considered a best
practice. Yet it isn't performed throughout the 'net. Solid programming
can be done, but if the individual(s) or company do not wish to take the
time to do it right, then it will have problems.
> Overhead. To get reasonable performance on boundary-checked arrays you
> need compiler to do deeper optimization than is possible with calling
> library routines (or even inlining them - because the semantics of
> procedure call is restrictive).
Let me get this strait. You have a language which is very low on
overhead and adding any overhead is unacceptable despite the fact that
it would still have less overhead than many other languages?
> I don't use flowcharts - they're less compact than text, so they hinder
> comprehension of complex pieces of code (it is a well-known fact that
> splitting text onto separate pages which need to be flipped back and forth
> significantly degrades speed and accuracy of comprehension - check any
> textbook on cognitive psychology). There were many graphical programming
> projects (this is a perinneal mania in programming tool-smith circles),
> none of them yielded any significant improvement in productivity or
> quality.
I imagine that they didn't. The flowchart was more of a training tool
than anything. I create 3 dimentional flowcharts in my head when dealing
with any process; programming or engineering. 9 times out of 10, I will
beat someone else to the solution to a problem. Why? Because I know how
to quickly break a process down from end to end into it's tiniest
pieces, rule out layers that don't apply to the problem and quickly
follow the path to where reality differs from theory.
> Sendmail is a horrible kludge, and, frankly, I'm amazed that it is still
> being supplied as a default MTA with Unix-like OS-es.
Yeah, but a flowchart on the wall would really look cool. :P
> A professional programmer will choose a language which lets him do the
> required job with minimal effort. Since quality is not generally a project
> requirement in this industry (for reasons I already mentioned) the result
> is predictable - use of languages which allow quick and dirty programming;
> getting stuff to do something fast, so it can be shipped, and screw the
> user, who is by now well-conditioned to do the three-finger salute instead
> of asking for refund.
Social issue, not technical. Change the perspective of the programmer,
project manager, etc, etc and the same language can be used to produce
quality code.
-Jack
More information about the NANOG
mailing list