WANTED: ISPs with DDoS defense solutions

Sat Aug 2 00:44:23 UTC 2003

On Fri, 1 Aug 2003, Jack Bates wrote:

> There is nothing in C which guarantees that code will be unreliable or 
> insecure.

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.

> C has the advantage of power and flexibility.

So does assembler - way more than C.

> It does no hand holding, so any idiot coder claiming to be a
> programmer can slap together code poorly. This is the fault of the
> programmer, and not the language.

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
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.

Some languages help to catch mistakes.  Some help them to stay unnoticed,
until a hacker kid with spermotoxicosis and too much free time comes
poking around.

> The syntax for C is just fine, and since any language is 
> nothing more than syntax, C is a workable language.

I'm afraid you're mistaken - a language is a lot more than syntax. Syntax
is easy, the semantics is hard.  To my knowledge, only one group ever
atempted to formally define semantics of a real programming language - and
what they produced is 300-something pages of barely readable "Algol-68:
The Revised Report" filled with statements in a context-dependent grammar.  
All _syntax_ for the same language fits in 6 pages.

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
some places, particulary when you want to write reusable code (hint:
STLport.com was hosted on one of my home boxes for some time :)  Java is
overly restrictive and has no support for generic programming (aka
templates), besides the insistence on garbage colletion makes it nearly
useless for any high-performance stuff.

Anyway, my point is not that there is an ideal language which everyone
must use, but rather that the existing ones are inadequate, and no serious
effort is being spent on getting them better (or even getting existing
better research languages into the field).  The lack of effort is simply a
consequence of lack of demand.

> There are libraries 
> out there for handling arrays with sanity checks. The fact that people 
> don't use them is their own fault.

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).

> For that matter, one can easily write their own. I don't know how many
> times I have gotten a vacant expression when mentioning the word
> flowchart; which is nothing more than the visual form of what any
> programmer should have going through their head (and on paper if they
> really want to limit mistakes).

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.

> What I'd give to see a detailed flowchart for sendmail. I'd hang it on
> my walls (as I'm sure it'd take more than one).

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.

> Write a small program in C and then write it in Perl.
> ... 
> Time both programs. For what it's worth,
> sorry Perl took so long.

Perl is interpreted, C is compiled. In fact, Perl is worse than C when it
comes to writing reliable programs, for obvious reasons.  If anything, I
wouldn't advocate using any of the new-fangled hack-and-run languages for
anything but writing 10-line scripts.

> If a programmer can write a process in any language, then naturally the 
> programmer should choose the language which provides the most 
> flexibility, performance, and diversity; or the right tool.

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.

--vadim