Re: Public disclosure of discovered vulnerabilities

On Wed, 25 May 2005 07:02:05 +0000, Bryan Olson wrote:
> Andrew Reilly wrote:
> > So, I guess my point is: combining the flexibility of assembly language
> > with the power of assembly language, while still being usefully portable
> > across platforms, is actually a pretty useful feature set, if the only
> > reasonable alternative is actual assembly language.
>
> And my response to your point is ... well ... yeah.
>
> Given the number of people and posts with whom and with which I
> disagree, I'm often amazed by how frequently I end up arguing in
> violent agreement. Then again, argument is what keeps Usenet
> interesting. You began the previous post in this strand with
> "Not true", so I pushed my point. I'm like that.

:-)

> So what is my own point? Today, the primary problem in Software
> Engineering is a correctness problem, which leads to a
> robustness problem, a reliability problem, and a security
> problem. The limiting factor on the vast majority of real-world
> programming challenges is the ability of humans to write correct
> code. Cost is always an issue, and the ability of advanced
> software development enterprises to produce reliable code at
> thousands of dollars, or tens of thousands of dollars per line
> is not a realistic solution.
>
> Today's arguments for moving from C to more advanced languages
> is very much like the case was, decades ago, for moving from
> Assembly to higher level languages such as C. "Never use
> Assembly," was wrong then, just as "never use C," is wrong now.
> Nevertheless, some people back then got it right; they realized
> that 98% of what was written in assembly would be better written
> in C.
>
> Progress continued. Machine resources have doubled about every
> year-and-a-half, while we humans remain as smart and as stupid
> as we've been for millennia. Today we should be focused on
> languages that are optimized for security, reliability,
> robustness, and more generally, for helping people to
> consistently deliver correct code. C was a terrific language,
> and it still has its place, but C is now decades behind the
> times.

I don't actually disagree with any of that. I'm all for correctness, but
quite a lot of the more modern languages are actually pretty poor
substitutes, when it comes to certain (large, important) niches, which is
a shame. The recognizably "PC" (and server/mainframe/HPC) part of
computing has followed that hardware progress that you mentioned by
producing ever more power and capacity at certain specific price points.
At the same time, the embededd/portable/gadget market has followed that
curve down in size to ever cheaper parts and systems that consume ever
smaller quantities of power (to extend battery life, for example). That's
a pretty huge and active part of the computing marketplace, and it does
involve programming.

However that programming generally still involves constraints like
absolute minimization of memory footprints, RAM/ROM/on and off-chip space
management and real-time response that rules out (or severely curtails)
dynamic memory management, let alone the garbage collection systems that
come along with most of the high profile, modern, safe languages.
Fortran, Pascal, Ada and Modula-2/3 could probably still find some uses,
but they suffer from the availability problem. C++ is a readily available
"modern" language, but it doesn't do anything for the safety problem.
Java/C#/Lisp/functional all suffer from a reliance on dynamic heap data
structures that simply don't offer the necessary level of control and
placement, have un-bounded and unknowable run-time and space overheads,
and which impose significant extra space and time overheads by having (for
example) no (packed, contiguous) arrays of compound user-defined types
(structs). Eiffel comes pretty close, now that it has a reasonable
compliment of basic numeric types, but has the "niche language" problem in
spades, as well as the dynamic memory problem. Got any suggestions? At
the moment, good top-level software design/architecture + C + regression
and unit tests + don't make any mistakes is really all there is. Maybe
you'll be able to find C++ instead of C in some places. Lots still
happens in assembly language, particularly in the DSP field.

If the other guy's widget runs for twice as long on the same set of
batteries, you'll be in trouble. Avoiding cycles to save power is almost
the same process as avoiding cycles because the processor wasn't fast
enough to win the SPEC/TPC/Linpac race. The difference is that you're not
inclined to address it by adding more silicon to perform bounds checks in
parallel with fetches, or the like: extra silicon costs area, which adds
to the build cost. Better to just not do unnecessary work at all.

I was under the impression that most of the new GUI and server style of
application code was already being written in things like Java, C#, lisp,
javascript, tcl and Python, or other "safe" languages. Is that not the
case? I've heard that Java programmers are easier to find than C++ ones,
now.

-- 
Andrew