RE: How Ada could have prevented the Red Code distributed denial of

RE: How Ada could have prevented the Red Code distributed denial of

[Beard, Frank]

LynxOS is real-time, off-the-shelf, general-purpose, and POSIX
compliant, as well.  We used it on space station, and it was 
pretty nice.  Tasks mapped to threads, etc.

It was faster on an IBM PS2 66 MHz than HP-UX BLS was on HP's
own 150 MHz MIPS processor.  And according to the HP reps HP's
real-time OS was a re-wrapped LynxOS, but I don't know if that's
still true.  We moved to NT before we ever got to try HP's
real-time OS.

Frank

-----Original Message-----
From: Tore Lund [mailto:tl001@online.no]
Sent: Thursday, August 23, 2001 5:22 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: How Ada could have prevented the Red Code distributed
denial of


Markus Mottl wrote:
> 
> Add these costs to the price of buying an off-the-shelve general-purpose
> OS and compare the result to the price of a real time OS for this
> specific purpose. Voila, your decision criterion for when to buy what
> kind of OS.

QNX is real-time, off-the-shelf and general-purpose, as well as
POSIX-compliant.  (At least according to QNX blurb.)  Has anyone
considered QNX for use on warships...?
-- 
    Tore

_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

How to make Ada a dominant language

[Russ]

The Ada programming language is based on an excellent fundamental
design, but it is much less popular than it could be because it has an
awkward, "klunky" syntax. I propose to clean up the syntax by
borrowing from Python. Python is very popular high level "scripting"
language with a reputation for promoting clean, clear code. The new
syntax could be translated into Ada95 syntax with a relatively simple
"preprocessor," so existing compilers could still be used, old code
would continue to work, and programmers could continue to use the old
syntax if they wish.

Here are the syntax changes I propose:

1. Eliminate the "end" keyword and make the indentation structure an
inherent part of the syntax, as in Python.

2. Eliminate the requirement for a semicolon after each executable
statement, but allow semicolons for combining multiple statements on a
line, as in Python.

3. Use "=" rather than ":=" for assignment, as in Python. (Use "=="
for equality testing if necessary to avoid confusion with assignment.)

4. Use "=" instead of "=>" for passing arguments by named association,
as in Python.

5. Reverse the backward declaration syntax. For example, use "integer:
count" instead of "count: integer", or use "integer in: count" instead
of "count: in integer".

6. Eliminate the "is" keyword.

7. Let "use" imply "with" so the tops of files need not be cluttered
with both "with" and "use" for the same package.

A flag on the first line of a source file (e.g., the string "Ada01"
anywhere within a comment) could be used to tell the compiler that the
file needs to be translated to Ada95 before compiling.

With these changes, I believe Ada would become much more popular and
could eventually become a dominant language. The resulting new
language could be called "Ada01," or something like that.

Honestly now, which of the following two statements is cleaner and
clearer?

    count: integer := 0;  -- old syntax

    integer: count = 0  -- new syntax

Russ Paielli
http://RussP.org

Re: How to make Ada a dominant language

[Preben Randhol]

In article <bebbba07.0107292308.d1192fc@posting.google.com>, Russ wrote:
> The Ada programming language is based on an excellent fundamental
> design, but it is much less popular than it could be because it has an
> awkward, "klunky" syntax. I propose to clean up the syntax by
> borrowing from Python. Python is very popular high level "scripting"
> language with a reputation for promoting clean, clear code. The new

If you compare it to Perl, yes.

> syntax could be translated into Ada95 syntax with a relatively simple
> "preprocessor," so existing compilers could still be used, old code
> would continue to work, and programmers could continue to use the old
> syntax if they wish.

 [snipped suggestions]
 
> 
> Honestly now, which of the following two statements is cleaner and
> clearer?
> 
>     count: integer := 0;  -- old syntax

Reads: Count is integer and set is to 0

> 
>     integer: count = 0  -- new syntax

Reads: Integer count equals 0

I prefer the old way, as it is easier to read.

Why is it so very important to use = to set a value and then == when you
check it? I have not understood this.

I don't at all agree that one should change the syntax. There is no need
to make the programs less readable. You should read your source code
more often than you write it. Besides none of these changes will make
Ada more popular, it will only make it a yet-another-language. Now Ada
has advantages over other languages and one is that it is highly readable.

Preben

-- 
�Don't use C;  In my opinion,  C is a library programming language
 not an app programming language.�  - Owen Taylor (GTK+ developer)

Use Ada 95, a free language. More info at http://www.adapower.com/

Re: How to make Ada a dominant language

[Russ Paielli]

Preben Randhol wrote:
> 
> In article <bebbba07.0107292308.d1192fc@posting.google.com>, Russ wrote:
> > The Ada programming language is based on an excellent fundamental
> > design, but it is much less popular than it could be because it has an
> > awkward, "klunky" syntax. I propose to clean up the syntax by
> > borrowing from Python. Python is very popular high level "scripting"
> > language with a reputation for promoting clean, clear code. The new
> 
> If you compare it to Perl, yes.
> 
> > syntax could be translated into Ada95 syntax with a relatively simple
> > "preprocessor," so existing compilers could still be used, old code
> > would continue to work, and programmers could continue to use the old
> > syntax if they wish.
> 
>  [snipped suggestions]
> 
> >
> > Honestly now, which of the following two statements is cleaner and
> > clearer?
> >
> >     count: integer := 0;  -- old syntax
> 
> Reads: Count is integer and set is to 0
> 
> >
> >     integer: count = 0  -- new syntax
> 
> Reads: Integer count equals 0
> 
> I prefer the old way, as it is easier to read.

I'll bet nine out of 10 non-Ada-programmers would disagree with you. And
that's part of the reason that nine out of ten programmers (or whatever)
are non-Ada-programmers.

> Why is it so very important to use = to set a value and then == when you
> check it? I have not understood this.

Because "=" is the simplest fricking symbol that could possibly be used
for assignment. Why is this so hard for Ada programmers to understand?
What's so great about ":="? Why not use "$=" or "%="?

> I don't at all agree that one should change the syntax. There is no need
> to make the programs less readable. You should read your source code
> more often than you write it. Besides none of these changes will make
> Ada more popular, it will only make it a yet-another-language. Now Ada
> has advantages over other languages and one is that it is highly readable.

What I am proposing would not make programs "less readable." It would
make them MORE readable, especially for new Ada programmers. If
long-time Ada programmers are unable to see that, I believe Ada will
become an obscure niche language, like HAL or Jovial. That would be a
terrible shame, because Ada has excellent fundamentals and could become
a dominant language.

Russ

Re: How to make Ada a dominant language

[Florian Weimer]

Russ Paielli <18k11tm001@sneakemail.com> writes:

>> I prefer the old way, as it is easier to read.
> 
> I'll bet nine out of 10 non-Ada-programmers would disagree with you.

I don't think so.  A look up variable declarations by variable name,
and not their type, so I'm quite glad that the variable name appears
at the left.  I find it hard to believe that anybody disagrees with
that.  After all, there is a long tradition of organizing things that
way (think of phone books).

> And that's part of the reason that nine out of ten programmers (or
> whatever) are non-Ada-programmers.

Hmm, that's a strange non sequitur in any case.

>> Why is it so very important to use = to set a value and then == when you
>> check it? I have not understood this.
> 
> Because "=" is the simplest fricking symbol that could possibly be used
> for assignment.

For most people with a non-FORTRAN background, '=' implies symmetry,
but an assignment is not symmetric.

> Why is this so hard for Ada programmers to understand?

Using '=' to denote anything but equality is confusing because it
contradicts the established meaning of that symbol (that's why I don't
like the big-oh notation either).

> What's so great about ":="? Why not use "$=" or "%="?

':=' was already used to denote assignent even before programming
languages existed.

> What I am proposing would not make programs "less readable." It would
> make them MORE readable, especially for new Ada programmers.

I don't think readability is a concern to beginners.  Many people
learn C just for fun.

Re: How to make Ada a dominant language

[Keith Thompson]

Florian Weimer <fw@deneb.enyo.de> writes:
> Russ Paielli <18k11tm001@sneakemail.com> writes:
[...]
> > What's so great about ":="? Why not use "$=" or "%="?
> 
> ':=' was already used to denote assignent even before programming
> languages existed.

Is that true?  I would have assumed that the concept of assignment
didn't exist, or at least wasn't very widespread, before programming
languages existed.  Equality assertions using "=" are far more common
in mathematics.

I had thought that assignment was originally indicated with an arrow
(like "<-", but a single character), then changed to ":=" because
there was no arrow character in the character set being used at the
time (an ancestor of ASCII).  This probably goes back to Algol,
perhaps earlier.

(If I weren't so lazy, I'd look it up in my History of Programming
Languages book; perhaps I will later if this thread doesn't die out.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: The concept of := (was How to make Ada a dominant language)

[Warren W. Gay VE3WWG]

Keith Thompson wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
> > Russ Paielli <18k11tm001@sneakemail.com> writes:
> [...]
> > > What's so great about ":="? Why not use "$=" or "%="?
> >
> > ':=' was already used to denote assignent even before programming
> > languages existed.
> 
> Is that true?  I would have assumed that the concept of assignment
> didn't exist, or at least wasn't very widespread, before programming
> languages existed.  Equality assertions using "=" are far more common
> in mathematics.

In response to "the concept of assignment didn't exist" :

Quoting from "Imperative Programming Languages: Vol II" 
by Peter H. Salus, Series Editor in Chief 
(ISBN 1-57870-009-4) :

"In 1954, a project was begun under the leadership 
of John Backus at IBM to develop an 'automatice 
programming' systemthat would convert programs 
written in a *mathematical notation* to machine 
instructions for the IBM 704 computer. Many were 
skeptical about the success of the project because, 
at the time, computer memories were so small and 
expensive and execution time so valuable that it 
was believed necesssary for the compiled program 
to be almost as efficient as that produced by a 
good assembly language programmer. ..."

The chapter goes on to describe the beginnings of FORTRAN.

The point of this excerpt was that there was a "mathematical
notation" in use. While this is not described, I would not be
surprised that any step-wise description would have some
sort of "assignment notation" like :=, since mathematics 
types would be loath to say =.

Further note that John Backus was involved here, and he is
the one behind "BNF". See

 http://www-groups.dcs.st-andrews.ac.uk/~history/Mathematicians/Backus.html

for picture and other background.

From http://www.digitalcentury.com/encyclo/update/backus.html :

"After FORTRAN, Backus turned his focus to other elements of 
computer programming. In 1959, he developed a notation called 
the Backus-Naur Form. It describes grammatical rules for 
high-level languages, and has been adapted for use in a 
number of languages."

What is interesting about BNF, it uses the ::= notation for
describing grammars, for example :

<postal-address> ::= <name-part> <street-address> <zip-part>

It's not hard to imagine that while grammar rules may use ::=,
then the assignment rule may indeed have been := .

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

How Ada could have prevented the Red Code distributed denial of service attack.

[raj]

Red Code uses a combination of:

1. Buffer overflow

See:
.ida "Code Red" Worm
http://www.eeye.com/html/Research/Advisories/AL20010717.html
for a recent , readable account see:

 Win32 Buffer Overflows (Location, Exploitation and Prevention) 
dark spyrit AKA Barnaby Jack 
http://www.phrack.org/show.php?p=55&a=15

2. Disseminated metastasis
see:
Distributed Metastasis:
A Computer Network Penetration Methodology 
by Andrew J. Stewart 

http://www.packetfactory.net/papers/Distributed_Metastatis/distributed_metastasis.doc
or Phrack 55
http://www.phrack.org/show.php?p=55&a=16

The buffer overflow occurs because of an old and well known bug in the
C libraries.
Using Ada or another modern language like Ocaml or Mozart could have
prevented this, thus stopping the worm before it infected the very
first IIS server.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Mike Smith]

"raj" <israelrt@optushome.com.au> wrote in message
news:ppsemtojqkqsqpfvj1th3mae8b4vu1tg89@4ax.com...
>
> The buffer overflow occurs because of an old and well known bug in the
> C libraries.

The buffer overflow occurs because of a bug in the *Microsoft* C library.
This is not endemic to C or C++ in general.  And, what, no one has ever
found a bug in Ada?

--
Mike Smith

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Scott Ingram]

Mike Smith wrote:
> 
> "raj" <israelrt@optushome.com.au> wrote in message
> news:ppsemtojqkqsqpfvj1th3mae8b4vu1tg89@4ax.com...
> >
> > The buffer overflow occurs because of an old and well known bug in the
> > C libraries.
> 
> The buffer overflow occurs because of a bug in the *Microsoft* C library.
> This is not endemic to C or C++ in general.  And, what, no one has ever
> found a bug in Ada?
> 
> --
> Mike Smith

I am not exactly sure what the point of "raj"'s post was,
but David Wheeler's "Secure Programming for Linux and Unix
HOWTO" (part of the Linux Documentation Project and also
available at http://www.dwheeler.com) covers this topic in
detail, as well as strategies for coping with it.  And of
course you can write buggy code in Ada--what's the point
of such a powerful language if you can't make it do what you
want?  Its just that you really have to want a buffer overflow
to make it happen :)
-- 
Scott Ingram
Vice-Chair, Baltimore SIGAda
System Development and Operational Support Group
Johns Hopkins University Applied Physics Laboratory

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Beelsebob]

[origional message]

So your point is that you can use a buggy microsoft implementation of
C++ to write a virus.

Now then let me see... oh yes, you can use Ada (not even a buggy
implementation of it) to cause the Arian 5 rocket to try and turn
round in mid flight, and disintegrate into many tinny little burrning
pieces.....

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Scott Ingram]

Beelsebob wrote:
> 
> [origional message]
> 
> So your point is that you can use a buggy microsoft implementation of
> C++ to write a virus.
> 
> Now then let me see... oh yes, you can use Ada (not even a buggy
> implementation of it) to cause the Arian 5 rocket to try and turn
> round in mid flight, and disintegrate into many tinny little burrning
> pieces.....

My point exactly.  Ada will do what you tell it to do:  including
telling an Ariane 5 to fly like an Ariane 4, even though it can't
possibly do that.  Though that does seem a higher level problem than
a buffer overflow, where you have to jump through some hoops to make
that happen.
-- 
Scott Ingram
Vice-Chair, Baltimore SIGAda
System Development and Operational Support Group
Johns Hopkins University Applied Physics Laboratory

Re: How Ada could have prevented the Red Code distributed denial of

[Larry Kilgallen]

In article <3B698522.EEE2A1F9@silver.jhuapl.edu>, Scott Ingram <scott@silver.jhuapl.edu> writes:
> Beelsebob wrote:
>> 
>> [origional message]
>> 
>> So your point is that you can use a buggy microsoft implementation of
>> C++ to write a virus.
>> 
>> Now then let me see... oh yes, you can use Ada (not even a buggy
>> implementation of it) to cause the Arian 5 rocket to try and turn
>> round in mid flight, and disintegrate into many tinny little burrning
>> pieces.....
> 
> My point exactly.  Ada will do what you tell it to do:  including
> telling an Ariane 5 to fly like an Ariane 4, even though it can't
> possibly do that.

That has the advantage that at least you can blame the failure on
management :-)

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Will]

theory: Ada could have rule the world as a superior language
Fact: it did not

theory: you could have write a better OS than NT, Linux, SunOS with Ada
Fact: there is *NO* Ada OS 

Why dont you Ada lovers go burn your NT, Linux, Sun OS box, because
theses OS are written in C.
See if you are left with an OS to write your Ada application.
Die, Ada, Die.

raj <israelrt@optushome.com.au> wrote in message news:<ppsemtojqkqsqpfvj1th3mae8b4vu1tg89@4ax.com>...
> Red Code uses a combination of:
> 
> 1. Buffer overflow
> 
> See:
> .ida "Code Red" Worm
> http://www.eeye.com/html/Research/Advisories/AL20010717.html
> for a recent , readable account see:
> 
>  Win32 Buffer Overflows (Location, Exploitation and Prevention) 
> dark spyrit AKA Barnaby Jack 
> http://www.phrack.org/show.php?p=55&a=15
> 
> 2. Disseminated metastasis
> see:
> Distributed Metastasis:
> A Computer Network Penetration Methodology 
> by Andrew J. Stewart 
> 
> http://www.packetfactory.net/papers/Distributed_Metastatis/distributed_metastasis.doc
> or Phrack 55
> http://www.phrack.org/show.php?p=55&a=16
> 
> The buffer overflow occurs because of an old and well known bug in the
> C libraries.
> Using Ada or another modern language like Ocaml or Mozart could have
> prevented this, thus stopping the worm before it infected the very
> first IIS server.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Richard Riehle]

Will wrote:

> Fact: there is *NO* Ada OS

It really depends on what you call an OS.   There is certainly
no OS equivalent to MS Windows, UNIX, or such.  However,
there are commercial, off-the-shelf (COTS) RTE's for embedded
systems that serve in the role of OS for those environments.  In
fact, they serve in that role far better than one of the more popular
OS could.  The U.S. Navy is discovering just how horrid NT is
after towing ships back to port because of failures.  Windows
XP promises to be no better.

Perhaps it is worthwhile for someone to write an OS in Ada that
supports desktop applications.  However, the real strength of Ada,
and its real application domain is safety-critical software.  The
currently available COTS Operating Systems from Ada compiler
publishers meets that need quite nicely, thank you.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Joachim Durchholz]

Richard Riehle <richard@adaworks.com> wrote:
>
> The U.S. Navy is discovering just how horrid NT is
> after towing ships back to port because of failures.

Could you share a reference to a report? The "more official", the better
(there are people who need convincing).

Regards,
Joachim
--
This is not an official statement from my employer.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Larry Kilgallen]

In article <9lvsic$bet9s$1@ID-9852.news.dfncis.de>, "Joachim Durchholz" <joachim_d@gmx.de> writes:
> Richard Riehle <richard@adaworks.com> wrote:
>>
>> The U.S. Navy is discovering just how horrid NT is
>> after towing ships back to port because of failures.
> 
> Could you share a reference to a report? The "more official", the better
> (there are people who need convincing).

I was under the impression that despite the troubles in the press reports,
the Navy was taking a full-steam-ahead attitude toward greater dependence
on Windows NT for such mission-critical roles.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Richard Bos]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote:

> I was under the impression that despite the troubles in the press reports,
> the Navy was taking a full-steam-ahead attitude toward greater dependence
> on Windows NT for such mission-critical roles.

That is good news. For the rest of us, that is ;->.

Richard

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Larry Kilgallen]

In article <3b83847d.1117251944@news.worldonline.nl>, info@hoekstra-uitgeverij.nl (Richard Bos) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote:
> 
>> I was under the impression that despite the troubles in the press reports,
>> the Navy was taking a full-steam-ahead attitude toward greater dependence
>> on Windows NT for such mission-critical roles.
> 
> That is good news. For the rest of us, that is ;->.

You are, of course, entitled to your opinion.  But it would appear
that you are only considering the possibility that if the US Navy
aimed at you they might miss.

Have you considered the possibility that the US Navy might hit you
when they were actually aiming at someone else ? :-)

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Ted Dennison]

In article <EJrOiAbJ3WLJ@eisner.encompasserve.org>, Larry Kilgallen says...
>
>In article <3b83847d.1117251944@news.worldonline.nl>, info@hoekstra-uitgeverij.nl (Richard Bos) writes:
>You are, of course, entitled to your opinion.  But it would appear
>that you are only considering the possibility that if the US Navy
>aimed at you they might miss.
>
>Have you considered the possibility that the US Navy might hit you
>when they were actually aiming at someone else ? :-)

Well, the software in question was the marine (engine) control system. It had
nothing to do with the weapon systems. I suppose you could get rammed...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Adam Fineman]

Ted Dennison wrote:
> 
> In article <EJrOiAbJ3WLJ@eisner.encompasserve.org>, Larry Kilgallen says...
> >
> >In article <3b83847d.1117251944@news.worldonline.nl>, info@hoekstra-uitgeverij.nl (Richard Bos) writes:
> >You are, of course, entitled to your opinion.  But it would appear
> >that you are only considering the possibility that if the US Navy
> >aimed at you they might miss.
> >
> >Have you considered the possibility that the US Navy might hit you
> >when they were actually aiming at someone else ? :-)
> 
> Well, the software in question was the marine (engine) control system. It had
> nothing to do with the weapon systems. I suppose you could get rammed...
> 
I'm in need of clarification.  Are you saying that a US Naval vessel's
engine control system was running under Windows NT?

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

-- 
Opinions posted here are my own.  They do not necessarily reflect those
of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B83F498.E0F6C582@timesys.com>, Adam Fineman says...
>
>Ted Dennison wrote:
>> Well, the software in question was the marine (engine) control system. It had
>> nothing to do with the weapon systems. I suppose you could get rammed...
>> 
>I'm in need of clarification.  Are you saying that a US Naval vessel's
>engine control system was running under Windows NT?

That was the idea. Scared yet? Well, then realise this was back in the days of
Windows NT 3.51, if I remember correctly. Also realise that Navy software is
expected to run proplerly for *decades* without maintanence upgrades like home
users are accustomed to. If you change something as significant as an OS, you
have to retest and recertify the whole system, which is incredibly expensive,
and thus not undertaken lightly.

I was particularly amused at part of one of the articles where they said the
vendor essentially blamed the problem on the Navy using an obsolete version of
their software. Perhaps home users have become resigned to being talked to that
way. But you simply do *not* go telling the Navy that all that softaware they
paid you millions to develop was really buggy crap, and thus they should pay you
again for an "upgrade".

I don't know what happened to this technology after that highly publicised
blowout. I suspect that at most it only got deployed on some of the newer
cruisers, and the Destroyers are all still using the reliably designed
Ada/Unix/CMS-2 stuff.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Ted Dennison wrote:
> 
> In article <3B83F498.E0F6C582@timesys.com>, Adam Fineman says...
> >
> >Ted Dennison wrote:
> >> Well, the software in question was the marine (engine) control system. It had
> >> nothing to do with the weapon systems. I suppose you could get rammed...
> >>
> >I'm in need of clarification.  Are you saying that a US Naval vessel's
> >engine control system was running under Windows NT?
> 
> That was the idea. Scared yet? Well, then realise this was back in the days of
> Windows NT 3.51, if I remember correctly. Also realise that Navy software is
> expected to run proplerly for *decades* without maintanence upgrades like home
> users are accustomed to. If you change something as significant as an OS, you
> have to retest and recertify the whole system, which is incredibly expensive,
> and thus not undertaken lightly.
> 
> I was particularly amused at part of one of the articles where they said the
> vendor essentially blamed the problem on the Navy using an obsolete version of
> their software. Perhaps home users have become resigned to being talked to that
> way. But you simply do *not* go telling the Navy that all that softaware they
> paid you millions to develop was really buggy crap, and thus they should pay you
> again for an "upgrade".
> 
> I don't know what happened to this technology after that highly publicised
> blowout. I suspect that at most it only got deployed on some of the newer
> cruisers, and the Destroyers are all still using the reliably designed
> Ada/Unix/CMS-2 stuff.

I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
was a member of the commisioning crew, in fact.  I did not realize that
this had ever been tried (using a Windows box to interface with the
engines).  I read the article linked elsewhere in this thread, and was
floored.  The USS Yorktown going DIW (dead in the water) actually
happened while I was on the Gonzalez!

We also we experimenting with the "Smart Ship" initiative, but no
existing ship's systems were ever going to be interfacing with the LAN
or any general-purpose OS.  The plan, as I recall, was only to add new
monitoring systems that would be run over a dedicated LAN.  I don't
think that it was ever intended that a general-purpose OS of any kind
would be used to _control_ ship's systems, only to monitor them.  That
was the plan on my ship, anyway.

Using a general-purpose OS (even a "high-end" Unix) to control any type
of machine more complicated than a household appliance seems like a very
silly idea to me.

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

-- 
Opinions posted here are my own.  They do not necessarily reflect those
of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B842DEA.E01CA1BE@timesys.com>, Adam Fineman says...
>I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
>was a member of the commisioning crew, in fact.  I did not realize that
>this had ever been tried (using a Windows box to interface with the
>engines).  I read the article linked elsewhere in this thread, and was
>floored.  The USS Yorktown going DIW (dead in the water) actually
>happened while I was on the Gonzalez!
..
>Using a general-purpose OS (even a "high-end" Unix) to control any type
>of machine more complicated than a household appliance seems like a very
>silly idea to me.

Well, if you had been on a the commisioning crew of a FLT-IIA ship (DDG 79 and
later, I believe), you would have been confronted with an engine controller
using Unix (HP/UX to be exact). There was also a redundant engine
monitor/controller running on NT 3.51 as an experiment, but as I said, it could
crash totally and not affect anything. I believe the Navy just wanted to try it
out shipboard to see how NT handled things. Both of these systems were of course
coded in Ada for extra reliability.

To give everyone else an idea of the lead times we are talking about here, I
think I finished up development on that system in '96, and the first ships with
them were commissoned last year. The sixth one won't be commissioned until 2003,
and there are currently plans for up to six more after that one. Who knows how
long they will be sailing after that. But during this whole time the Navy is
going to need copies of the OS and the ability to purchase spare motherboards,
etc. of 1995 vintage. Not many vendors keep the capability of making "obsolete"
parts for more that a couple of years. This is why many are a bit skeptical
about using commercial technology.

>We also we experimenting with the "Smart Ship" initiative, but no
>existing ship's systems were ever going to be interfacing with the LAN
>or any general-purpose OS.  The plan, as I recall, was only to add new
>monitoring systems that would be run over a dedicated LAN.  I don't

That my be a reference to my NT system. (Please don't tell the users it was me.
I did what I could, but, well, it was NT 3.51...)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Ted Dennison wrote:
> 
> In article <3B842DEA.E01CA1BE@timesys.com>, Adam Fineman says...
> >I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
> >was a member of the commisioning crew, in fact.  I did not realize that
> >this had ever been tried (using a Windows box to interface with the
> >engines).  I read the article linked elsewhere in this thread, and was
> >floored.  The USS Yorktown going DIW (dead in the water) actually
> >happened while I was on the Gonzalez!
> ..
> >Using a general-purpose OS (even a "high-end" Unix) to control any type
> >of machine more complicated than a household appliance seems like a very
> >silly idea to me.
> 
> Well, if you had been on a the commisioning crew of a FLT-IIA ship (DDG 79 and
> later, I believe), you would have been confronted with an engine controller
> using Unix (HP/UX to be exact).

Sounds like a horribly bad idea to me.  I don't have any particular
complaints about HP/UX as a general-purpose operating system, but it is
_not_ a real time OS and should not be used to run the engines of a
warship.

> There was also a redundant engine
> monitor/controller running on NT 3.51 as an experiment, but as I said, it could
> crash totally and not affect anything. I believe the Navy just wanted to try it
> out shipboard to see how NT handled things. Both of these systems were of course
> coded in Ada for extra reliability.
> 
Even if a perfect program were written (in any language) and it ran as a
process in a non-real-time general-purpose OS, it would be a bad idea.

<snip>

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

-- 
Opinions posted here are my own.  They do not necessarily reflect those
of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Gary Scott]

Hi,
Concurrent/Harris on the other hand has an excellent "real-time unix".

http://www.ccur.com

However, we've actually been successfully using Solaris in a real-time
environment for avionics models.

Adam Fineman wrote:
> 
> Ted Dennison wrote:
> >
> > In article <3B842DEA.E01CA1BE@timesys.com>, Adam Fineman says...
> > >I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
> > >was a member of the commisioning crew, in fact.  I did not realize that
> > >this had ever been tried (using a Windows box to interface with the
> > >engines).  I read the article linked elsewhere in this thread, and was
> > >floored.  The USS Yorktown going DIW (dead in the water) actually
> > >happened while I was on the Gonzalez!
> > ..
> > >Using a general-purpose OS (even a "high-end" Unix) to control any type
> > >of machine more complicated than a household appliance seems like a very
> > >silly idea to me.
> >
> > Well, if you had been on a the commisioning crew of a FLT-IIA ship (DDG 79 and
> > later, I believe), you would have been confronted with an engine controller
> > using Unix (HP/UX to be exact).
> 
> Sounds like a horribly bad idea to me.  I don't have any particular
> complaints about HP/UX as a general-purpose operating system, but it is
> _not_ a real time OS and should not be used to run the engines of a
> warship.
> 
> > There was also a redundant engine
> > monitor/controller running on NT 3.51 as an experiment, but as I said, it could
> > crash totally and not affect anything. I believe the Navy just wanted to try it
> > out shipboard to see how NT handled things. Both of these systems were of course
> > coded in Ada for extra reliability.
> >
> Even if a perfect program were written (in any language) and it ran as a
> process in a non-real-time general-purpose OS, it would be a bad idea.
> 
> <snip>
> 
> --
> Adam Fineman
> Software Engineer
> QA Department
> TimeSys Corporation
> 
> --
> Opinions posted here are my own.  They do not necessarily reflect those
> of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Gary Scott wrote:
> 
> Hi,
> Concurrent/Harris on the other hand has an excellent "real-time unix".
> 
As does my company. :-)  As do several others.

> However, we've actually been successfully using Solaris in a real-time
> environment for avionics models.
> 
I'm not sure I understand.  In what capacity have you been using Solaris
in a real-time environment?

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

-- 
Opinions posted here are my own.  They do not necessarily reflect those
of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Markus Mottl]

In comp.lang.functional Adam Fineman <adam.fineman@timesys.com> wrote:
> Sounds like a horribly bad idea to me.  I don't have any particular
> complaints about HP/UX as a general-purpose operating system, but it
> is _not_ a real time OS and should not be used to run the engines of
> a warship.

A real time OS makes guarantees about the maximum time it requires to
handle certain operations. This does not mean that a general-purpose
(non-real-time) OS is useless for real time tasks: it's all a matter of
latencies, probabilities and costs.

Given the probability distribution of the time the OS requires to handle
some critical request, you can very well compute how probable it is that
it will not be able to do so in time: just integrate the area below
the probability density function to the right of the maximum allowed
latency. Then multiply this probability with the costs of e.g. having
some warship dead in the water.

Add these costs to the price of buying an off-the-shelve general-purpose
OS and compare the result to the price of a real time OS for this
specific purpose. Voila, your decision criterion for when to buy what
kind of OS.

Of course, the probability density function and the costs of losing
a warship may be difficult to estimate, but I hope the Navy employs
competent managers + technical staff for that purpose.

Anyway, I don't know anything about the requirements of warship engines
so maybe our current general-purpose OSes are not good enough...

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Markus Mottl wrote:
> 
> In comp.lang.functional Adam Fineman <adam.fineman@timesys.com> wrote:
> > Sounds like a horribly bad idea to me.  I don't have any particular
> > complaints about HP/UX as a general-purpose operating system, but it
> > is _not_ a real time OS and should not be used to run the engines of
> > a warship.
> 
> A real time OS makes guarantees about the maximum time it requires to
> handle certain operations. This does not mean that a general-purpose
> (non-real-time) OS is useless for real time tasks: 

IMO a non-real-time OS is useless for this particular real time task.

> it's all a matter of
> latencies, probabilities and costs.
> 
> Given the probability distribution of the time the OS requires to handle
> some critical request,

Given?  Who gave you that, exactly?  ;-)  The rest of the calculation
you describe is fairly trivial.  The only hard part what you assume to
be given....

> you can very well compute how probable it is that
> it will not be able to do so in time: just integrate the area below
> the probability density function to the right of the maximum allowed
> latency. Then multiply this probability with the costs of e.g. having
> some warship dead in the water.
> 
> Add these costs to the price of buying an off-the-shelve general-purpose
> OS and compare the result to the price of a real time OS for this
> specific purpose. Voila, your decision criterion for when to buy what
> kind of OS.
> 
> Of course, the probability density function and the costs of losing
> a warship may be difficult to estimate, but I hope the Navy employs
> competent managers + technical staff for that purpose.
> 
It really doesn't matter how competent the Navy's "managers & technical
staff" are; the probability density function you would require is not
determinable in the real world.  This probability density function _can_
be determined for a properly implemented real time system, but not for a
general-purpose OS in this situation.

The cost of a warship is easily determined.  For example, my ship had a
sticker price of about 900,000,000 USD.  Of course, one can't determine
the cost of the 330 odd crewmembers or the possibility of losing a war
because a ship goes DIW at the wrong moment.

Hard real time systems are used when the cost of a missed deadline is
prohibitive.  Controlling the engines of a warship certainly qualifies.

By the way, have you ever heard of the Mars Pathfinder mission?

- Adam

-- 
Adam Fineman
SQA Engineer
TimeSys Corporation
-- 
Opinions posted here are my own.

Re: How Ada could have prevented the Red Code distributed denial of

[Tore Lund]

Markus Mottl wrote:
> 
> Add these costs to the price of buying an off-the-shelve general-purpose
> OS and compare the result to the price of a real time OS for this
> specific purpose. Voila, your decision criterion for when to buy what
> kind of OS.

QNX is real-time, off-the-shelf and general-purpose, as well as
POSIX-compliant.  (At least according to QNX blurb.)  Has anyone
considered QNX for use on warships...?
-- 
    Tore

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B85294F.BB780B7F@timesys.com>, Adam Fineman says...
>
>Ted Dennison wrote:
>> later, I believe), you would have been confronted with an engine controller
>> using Unix (HP/UX to be exact).
>
>Sounds like a horribly bad idea to me.  I don't have any particular
>complaints about HP/UX as a general-purpose operating system, but it is
>_not_ a real time OS and should not be used to run the engines of a
>warship.

Well, I had a longstanding debate with a lot of those folks about whether it was
really "real-time" or not. Its certianly not "hard" real-time. Since the system
doesn't make any decisions w/o an operator, who desginates his decision via a
GUI action, the performance tolerances are rather loose by my standards.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Markus Mottl]

In comp.lang.functional Joachim Durchholz <joachim_d@gmx.de> wrote:
> Could you share a reference to a report?

Here is a somewhat longer treatment of the case:

  http://www.jerrypournelle.com/reports/jerryp/Yorktown.html

In short: a divide-by-zero in a database caused a Windows NT server to
crash, paralyzing the whole computer network on the cruiser Yorktown
for more than two hours.

As usual, official reports (i.e. by the Navy itself) that indicate
shortcomings of their weapon technology do not circulate for too long
for obvious reasons (but maybe they are just hidden well enough).

There are plenty of serious media that report on the case, e.g. Government
Computing News:

  http://www.gcn.com/archives/gcn/1998/december14/39.htm
  http://www.gcn.com/vol18_no36/com/903-1.html

> The "more official", the better (there are people who need convincing).

The inofficial ones are funny, too:

  http://www.atlas-club.com.au/jokes/aviation/jokesav2.htm

The frightening about some jokes is that they seem so realistic ;)

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Ted Dennison]

In article <9m0193$grs$1@bird.wu-wien.ac.at>, Markus Mottl says...
>
>In comp.lang.functional Joachim Durchholz <joachim_d@gmx.de> wrote:
>> Could you share a reference to a report?
>As usual, official reports (i.e. by the Navy itself) that indicate
>shortcomings of their weapon technology do not circulate for too long
>for obvious reasons (but maybe they are just hidden well enough).

Well, I should point out that this isn't really "weapons technology". Its just
the engine control systems. The weapons are controlled by completely different
systems.

>
>There are plenty of serious media that report on the case, e.g. Government
>Computing News:
>
>  http://www.gcn.com/archives/gcn/1998/december14/39.htm
>  http://www.gcn.com/vol18_no36/com/903-1.html

I used to work at a place that was the competitor to the company that supplied
this system. I could add a lot of semi-insider elaboration to all this, but
that's probably best done in private (perhaps over a beer or two). If Jerry
Petrey's reading, he may have more info on this than I do.

This is actually a bit *worse* than it may sound to a civilian. I understand
that for a Navy captain, having to be towed in to port is a rough equivalent in
embarassment to being publicly gelded and then paraded through town. We would
occasionally have engineers *flown*out* to ships to aviod this...

We offered a system using technology hand-picked for reliability. Our legacy
stuff was all CMS-2, but for new work we bid Unix and Ada. We once even tried
out NT, and it was purposely put on a non-critical redundant device, to aviod
the possiblity of it causing a failure all by itself.

Our competitor got themselves a R&D contract, and proceeded to use the most
buzzword-compliant technologies they could find (at the time, NT and C++, with
some AI thrown in for good measure). They then tried to leverage their R&D work
into actual production for new ships, with the brass that was in charge of the
R&D work championing them. What you read above is the result. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Jerry Petrey]

Ted Dennison wrote:
> 
> In article <9m0193$grs$1@bird.wu-wien.ac.at>, Markus Mottl says...
> >
> >In comp.lang.functional Joachim Durchholz <joachim_d@gmx.de> wrote:
> >> Could you share a reference to a report?
> >As usual, official reports (i.e. by the Navy itself) that indicate
> >shortcomings of their weapon technology do not circulate for too long
> >for obvious reasons (but maybe they are just hidden well enough).
> 
> Well, I should point out that this isn't really "weapons technology". Its just
> the engine control systems. The weapons are controlled by completely different
> systems.
> 
> >
> >There are plenty of serious media that report on the case, e.g. Government
> >Computing News:
> >
> >  http://www.gcn.com/archives/gcn/1998/december14/39.htm
> >  http://www.gcn.com/vol18_no36/com/903-1.html
> 
> I used to work at a place that was the competitor to the company that supplied
> this system. I could add a lot of semi-insider elaboration to all this, but
> that's probably best done in private (perhaps over a beer or two). If Jerry
> Petrey's reading, he may have more info on this than I do.
> 
> This is actually a bit *worse* than it may sound to a civilian. I understand
> that for a Navy captain, having to be towed in to port is a rough equivalent in
> embarassment to being publicly gelded and then paraded through town. We would
> occasionally have engineers *flown*out* to ships to aviod this...
> 
> We offered a system using technology hand-picked for reliability. Our legacy
> stuff was all CMS-2, but for new work we bid Unix and Ada. We once even tried
> out NT, and it was purposely put on a non-critical redundant device, to aviod
> the possiblity of it causing a failure all by itself.
> 
> Our competitor got themselves a R&D contract, and proceeded to use the most
> buzzword-compliant technologies they could find (at the time, NT and C++, with
> some AI thrown in for good measure). They then tried to leverage their R&D work
> into actual production for new ships, with the brass that was in charge of the
> R&D work championing them. What you read above is the result.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com


I think you covered it pretty well, Ted.  We had a very good
implementation
of the engine controller in Ada but the management was so poor that they
allowed
it to be re-written (after I left) in C or C++ from what I've heard - to
be
more 'politically correct'.  That was their downfall.


Jerry

-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to
reply                  
-----------------------------------------------------------------------------

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B83F9D6.73CB3E02@west.raytheon.com>, Jerry Petrey <"jdpetrey
says...
>I think you covered it pretty well, Ted.  We had a very good
>implementation of the engine controller in Ada but the management was so poor >that they allowed it to be re-written (after I left) in C or C++ from what 
>I've heard - to be more 'politically correct'.  That was their downfall.

Well, bad management is everyone's downfall unfortunately. I think Jerry's
referring to another R&D engine controller, not the ones on the actual
production destroyers (at least I hope he is). The manager in charge of that was
just about the worst kind you can have: the idiot who thinks he is a genius. An
idiot manager who knows he's an idiot and sticks to leading and listening can
actually be quite good, but this other kind just destroys everything he touches.


I can remember the IM (idiot manager) informing a visiting prospective customer
that we were porting that perfectly working engine controller to C++ from Ada.
When the customer incredulously asked why we'd do such a useless thing, IM told
him essentialy that he, the customer, would refuse to buy it no matter how good
the specs, if it were coded in Ada internally rather than the current hot new
language. I'm guessing IM truly believed this. Apparently the prospective
customer was not horribly impressed with IM's sensitivity to his heretofore
undiscovered coding language "hipness" desire for his engine controllers,
because he never did buy anything from us. :-)

Of course they could very well have switched the Navy production stuff too. The
pressure to use "commerical" technologies was quite intense there for a while.
While I was there they were resisting somewhat because their main contracting
agencies were (wisely) quite suspicious of that trend. The needs of most
commercial users and of a battlefield shipboard environment are just *too*
different (Can your PC sustain 100G's of shock and vibration?). But I don't know
what has happened since.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Richard Riehle]

Ted Dennison wrote:

> I can remember the IM (idiot manager) informing a visiting prospective customer
> that we were porting that perfectly working engine controller to C++ from Ada.
> When the customer incredulously asked why we'd do such a useless thing, IM told
> him essentialy that he, the customer, would refuse to buy it no matter how good
> the specs, if it were coded in Ada internally rather than the current hot new
> language.

There truly is no end to this kind of stupidity.   I regularly encounter people who
seriously believe they can acheive the same reliability in C++ that they can with Ada.
Sadly, even some really competent technical people accept this argument, for reasons
they know have nothing to do with technological excellence.   Over and over I hear
the story, "Well Ada is probably better, but C++ is just as good if we use it carefully,"
or "I can do just as well as C++ as with Ada, even though I'll admit Ada is a better
language."    It is quite frustrating.

On the positive side, some of those who have made the decision to migrate to C++
made that decision without fully understanding its implications.   Once they discover
how hideous C++ is, they back off and decide to use Java.  The thought of returning
to Ada is simply too repugnant to them.

Richard Riehle

Re: How Ada could have prevented the Red Code distributed denial of

[tmoran]

>On the positive side, some of those who have made the decision to migrate to C++
>made that decision without fully understanding its implications.   Once they discover
>how hideous C++ is, they back off and decide to use Java.  The thought of returning
>to Ada is simply too repugnant to them.
  It's one thing to announce there's an even better solution than the one
you originally proposed.  It's another to admit your original idea stunk.

Re: How Ada could have prevented the Red Code distributed denial of

[Garry Hodgson]

Ted Dennison wrote:

> The manager in charge of that was
> just about the worst kind you can have: the idiot who thinks he is a genius. An
> idiot manager who knows he's an idiot and sticks to leading and listening can
> actually be quite good, but this other kind just destroys everything he touches.

i once had a conversation with a friend, and commented that i liked the
fact
that my boss had a good knowledge of software.  he replied that he had
the
next best thing:  his boss didn't know software, but knew that he didn't
know
software.

-- 
Garry Hodgson                   sometimes we ride on your horses
Senior Hacker                   sometimes we walk alone
Software Innovation Services    sometimes the songs that we hear
AT&T Labs                       are just songs of our own
garry@sage.att.com

Re: How Ada could have prevented the Red Code distributed denial of

[Samuel T. Harris]

Garry Hodgson wrote:
> 
> Ted Dennison wrote:
> 
> > The manager in charge of that was
> > just about the worst kind you can have: the idiot who thinks he is a genius. An
> > idiot manager who knows he's an idiot and sticks to leading and listening can
> > actually be quite good, but this other kind just destroys everything he touches.
> 
> i once had a conversation with a friend, and commented that i liked the
> fact
> that my boss had a good knowledge of software.  he replied that he had
> the
> next best thing:  his boss didn't know software, but knew that he didn't
> know
> software.
> 

1. he who knows not and knows not that he knows not is a fool, shun him
2. he who knows not and knows that he knows not is ignorant, teach him
3. he who knows and knows not that he knows is asleep, wake him
4. he who knows and knows that he knows is wise, follow him

There is no reasoning with a fool, so don't bother trying.
If he who is asleep refuses to be awakened then reclassify as 1.
We'd all like to think we classify as 4 but actually most of us
are a 2 or 3 in most areas of our lives. It is nice when we
are occasionally recognized as a number 4 in some small area
of our lives but none of us can be all knowing all the time.
That is what makes living interesting.


-- 
Samuel T. Harris, Senior Software Engineer II
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Chris Torek]

In article <%CX97.14134$ar1.47393@www.newsranger.com>
Ted Dennison <dennison@telepath.com> writes:
>Raj pretty much had the right of it. Exploitable buffer overflows are
>a known *class* of bugs that are pretty much endemic with C (and C++
>that uses C) code.

And other languages that offer interfaces to existing C (and C++)
libraries, for instance.

>On the other hand, you actually have to go fairly far out of your way
>to get an exploitable buffer overflow out of Ada code. ... [ref to
>site with ways to exploit Windows bugs elided]

Ultimately, this boils down to an indisputable fact: people are
exploiting buffer overflows that exist because poorly written C
code is popular.  But this practically begs for a new question: if
poorly-written Ada (or any other language) were popular instead,
would that mean there would be *no* exploitable bugs?  Or would the
exploitable bugs take some other form entirely?  Perhaps, if the
world were different, someone would be posting to comp.lang.ada an
article saying: "If only Zerble were the popular language, these
bugs would not be resulting in all these worms and viruses." :-)

(Over here in comp.lang.c, I just try to convince people that
writing exploitable bugs is a bad idea.)
-- 
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
El Cerrito, CA, USA     Domain: torek@bsdi.com  +1 510 234 3167
http://claw.eng.bsdi.com/torek/  (not always up)  I report spam to abuse@.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Ed Falis]

Goran Larsson wrote:
> 
> In article <9k9if8$rn3$1@elf.eng.bsdi.com>,
> Chris Torek  <torek@BSDI.COM> wrote:
> 
> > But this practically begs for a new question: if
> > poorly-written Ada (or any other language) were popular instead,
> > would that mean there would be *no* exploitable bugs?
> 
> No, it would mean that Arianne 5 rockets would tip over, break up,
> explode, and fall down. Hmmm... didn't that happen a while ago?
> 
> --
> G�ran Larsson     Senior Systems Analyst    hoh AT approve DOT se

Read the report.

- Ed

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Preben Randhol]

On Thu, 2 Aug 2001 05:21:25 GMT, Goran Larsson wrote:
> In article <3B687EDF.9359F3FC@mediaone.net>,
> Ed Falis  <efalis@mediaone.net> wrote:
> 
>> Read the report.
> 
> I have. Your point is?

Perhaps read it again.

Preben
-- 
�Don't use C;  In my opinion,  C is a library programming language
 not an app programming language.�  - Owen Taylor (GTK+ developer)

Use Ada 95, a free language. More info at http://www.adapower.com/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Tor Rustad]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> On Thu, 2 Aug 2001 05:21:25 GMT, Goran Larsson wrote:
> > In article <3B687EDF.9359F3FC@mediaone.net>,
> > Ed Falis  <efalis@mediaone.net> wrote:
> >
> >> Read the report.
> >
> > I have. Your point is?
>
> Perhaps read it again.

Looks like I need to read the report again aswell. :-)

IIRC, the problem was related to excetion handling of a hardware fault...not
exactly a Ada programming bug, but more a technical design bug...?

--
Tor <torust AT online DOT no>
"C is not a big language, and is not well served by a big book." -- K&R2

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Mike Silva]

"Tor Rustad" <torust@online.no.spam> wrote in message news:<PNha7.3185$e%4.96222@news3.oke.nextra.no>...
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> > On Thu, 2 Aug 2001 05:21:25 GMT, Goran Larsson wrote:
> > > In article <3B687EDF.9359F3FC@mediaone.net>,
> > > Ed Falis  <efalis@mediaone.net> wrote:
> > >
> > >> Read the report.
> > >
> > > I have. Your point is?
> >
> > Perhaps read it again.
> 
> Looks like I need to read the report again aswell. :-)
> 
> IIRC, the problem was related to excetion handling of a hardware fault...not
> exactly a Ada programming bug, but more a technical design bug...?

Very briefly, they had proven to their satisfaction that the offending
variable could never go out of range (of a 16 bit integer) on the
Ariane 4, and any unhandled exception, such as the one that occurred
when it *did* go out of range on the -5, was presumed to be due to a
hardware fault, leading to shutdown of the unit.  Since both units
received the same "impossible" value, due to the -5s different
trajectory, both shut down...

Not only wasn't it a programming bug, I wouldn't even call it a design
bug, since hardware failure would have been the correct presumption
based on the Ariane 4 trajectory data.  It was an untested,
unjustified re-use bug.

Mike

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Tor Rustad]

"Mike Silva" <mjsilva@jps.net> wrote in message
> "Tor Rustad" <torust@online.no.spam> wrote in message
> >
> > IIRC, the problem was related to excetion handling of a hardware
> > fault...not
> > exactly a Ada programming bug, but more a technical design bug...?
>
> Very briefly, they had proven to their satisfaction that the offending
> variable could never go out of range (of a 16 bit integer) on the
> Ariane 4, and any unhandled exception, such as the one that occurred
> when it *did* go out of range on the -5, was presumed to be due to a
> hardware fault, leading to shutdown of the unit.  Since both units
> received the same "impossible" value, due to the -5s different
> trajectory, both shut down...

Since both HW units got the same "impossible" value, it looks to me as the
probability for a HW fault should have been insignificant. The point in
verifying calculations in independent HW, is to detect and recover from HW
faults. So since the result from *both* HW units was the same, my conclusion
would be that it was a programming/design bug and not a HW fault. However,
error recovery from this type of errors (in general) is very difficult (if
not impossible).

Hmm...in fact for that reason, I have always assumed that in extremely
critical systems, you simply use independent design teams (and programmers)
to develop the second unit, and *not* just duplicate the first unit (which
must have the same identical bugs or flaws).

IMHO, using 16-bit integers, is also a design issue. If there was strict
performance requirements to be met, well then why not use a faster
programming language, where the programmers perhaps could afford to use
32-bit integers? Even in non-critical systems, I do think that many
programmers try to take future demands into consideration and make sure
their SW works not only according to current specs. Since they know that
somebody else may later change other parts of the system, possibly without
re-testing all the SW again.

> Not only wasn't it a programming bug, I wouldn't even call it a design
> bug, since hardware failure would have been the correct presumption
> based on the Ariane 4 trajectory data.  It was an untested,
> unjustified re-use bug.

To re-use an old design or not, is also design descision IMHO. Not testing
it, is a really bad descision, perhaps the biggest one in this sad story.

--
Tor <torust AT online DOT no>

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[James Rogers]

Tor Rustad wrote:
> 
> IMHO, using 16-bit integers, is also a design issue. If there was strict
> performance requirements to be met, well then why not use a faster
> programming language, where the programmers perhaps could afford to use
> 32-bit integers? Even in non-critical systems, I do think that many

There is no such thing as a faster programming language. Certain
compilers may produce faster code. Some compilers allow you to select
optimization for a balance of speed and code size. These optimizations
are not a language issue. They are compiler implementation issues.

Just ask yourself. "How fast is C? How Fast is C++?" There is no
answer to that question. Speed is not specified in any language
reference manual. 

There may not be a lot of performance improvement when using 64 bit
floating point numbers and converting them to 16 bit integers.
The conversion overhead itself is not trivial. It is certainly not
free of potential errors, as the Ariane 5 design clearly shows.

Jim Rogers
Colorado Springs, Colorado USA

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Tor Rustad]

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> Tor Rustad wrote:
> >
> > IMHO, using 16-bit integers, is also a design issue. If there was strict
> > performance requirements to be met, well then why not use a faster
> > programming language, where the programmers perhaps could afford to use
> > 32-bit integers? Even in non-critical systems, I do think that many
>
> There is no such thing as a faster programming language. Certain
> compilers may produce faster code. Some compilers allow you to select
> optimization for a balance of speed and code size. These optimizations
> are not a language issue. They are compiler implementation issues.

Not quite, when using a language which has built in security mechanisms on
a target which doesn't support these features natively (in HW), then there
will simply be a performance penalty. It may be significant, or it may very
well not be. In this case, perhaps it was?

> Just ask yourself. "How fast is C? How Fast is C++?" There is no
> answer to that question. Speed is not specified in any language
> reference manual.

Yes, comparing C vs C++ can be silly, more so when the code have identical
syntax. In the Ariane case, there was particular target (HW plattform), I am
shure there was performance differences between using different
languages/compilers/optimizers for this target.

Write a "Hello world!" program in Java, and name one single case for which
my C version will run slower. ;-)

In real life the language used do matter, so does the algorithms, compiler
and optimizer for that matter. Some langages support performance contructs,
e.g. in C99 we have const, restrict and volatile keyword, which let the
programmer control optimizations at low level. An other example is the
floating point conversion rules in C, which may give rather poor
floating-point performance (compared to for example a Fortran program), but
it depends on the target etc.

--
Tor <torust AT online DOT no>
"The practical scientist is trying to solve tomorrow's problem with
yesterday's computer; the computer scientist, we think, often has it the
other way around.", - NR on float conversion rules in C89

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Ted Dennison]

In article <xpTa7.3738$e%4.109789@news3.oke.nextra.no>, Tor Rustad says...
>
>Write a "Hello world!" program in Java, and name one single case for which
>my C version will run slower. ;-)

That's a bogus comparison. You are thinking of Java's propensity to create
interpreted code. That has nothing to do with Ada. (Although I suspect a Java
expert could probably accomplish it with JINI and a natively-targeted Java
compiler. Remember, "printf" actually has to stop and interpret the input string
to look for replacements. There's plenty of room for a speed improvement there).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[David Lee Lambert]

On Mon, 6 Aug 2001, Ted Dennison wrote:

> In article <xpTa7.3738$e%4.109789@news3.oke.nextra.no>, Tor Rustad says...
> >
> >Write a "Hello world!" program in Java, and name one single case for which
> >my C version will run slower. ;-)
>
> That's a bogus comparison. You are thinking of Java's propensity to create
> interpreted code. That has nothing to do with Ada. (Although I suspect a Java
> expert could probably accomplish it with JINI and a natively-targeted Java
> compiler. Remember, "printf" actually has to stop and interpret the input string
> to look for replacements. There's plenty of room for a speed improvement there).

One could use puts() instead:

#include <stdio.h>

int main()
{
  puts("Hello World"); /* function adds a \n */
  fflush(stdout);  /* actually implied... */
  return 0;
}

Practical comparison:  a "Hello World" program in Java actually takes
about 10 seconds to run on my 486, 33MHz.  A fairly complex
terminal-emulator loads up in a fraction of a second,  as does any program
I've ever written in C.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <Pine.GSO.4.30.0108071538190.29788-100000@scully>, David Lee Lambert
says...
>
>On Mon, 6 Aug 2001, Ted Dennison wrote:
>
>> That's a bogus comparison. You are thinking of Java's propensity to create
>> interpreted code. That has nothing to do with Ada. (Although I suspect a Java
>> expert could probably accomplish it with JINI and a natively-targeted Java
>> compiler. Remember, "printf" actually has to stop and interpret the input 
..
>One could use puts() instead:

That's not the issue. My points were:
a) Java's bytecode interpretation speed issues have nothing whatsoever to do
with Ada, any more than they do C. I repeat, *nothing*.
b) If I took the most natural language Y "hello world", an expert in language X
can most likely construct a quicker version for language X (even when X=Java and
Y=C, I suspect).  If you can turn around and do the same thing with tuned C and
a dumb Java implementation, you only provide *more* evidence of this.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Micah Cowan]

randhol+abuse@pvv.org (Preben Randhol) writes:

> On Wed, 1 Aug 2001 09:09:12 -0400, Mike Smith wrote:
> 
> > The buffer overflow occurs because of a bug in the *Microsoft* C library.
> > This is not endemic to C or C++ in general.  
> 
> The point is that if you look at the security bugs in Linux or Microsoft
> software they consists mainly of buffer overflow bugs. This comes from
> using languages such as C and C++ which allow buffer overflow due to
> their design. Other languages eliminate this problem to a large extent.

And implementations for these other languages are typically written in
what?  Hm?

If you confine yourself to safe string use, you will have no
difficulties.  Power always comes at the risk of its abuse. So?

"Modern" languages such as, oh, say Perl and Python, have no known
buffer overflow problems.  But what did the authors use to implement
them with?  So, if these buffer-stable languages are implemented in
"unsafe" languages such as C and C++; how were they able to write
"safe" language implementations in them?  Oh! Oh!  Pick me!  I know!

...careful design and programming (good ideas for any language).

Micah

-- 
"Everytime you declare main() as returning void - somewhere a little
baby cries.  So please, do it for the children."  -- Daniel Fox

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Ed Falis]

Micah Cowan wrote:

> > The point is that if you look at the security bugs in Linux or Microsoft
> > software they consists mainly of buffer overflow bugs. This comes from
> > using languages such as C and C++ which allow buffer overflow due to
> > their design. Other languages eliminate this problem to a large extent.
> 
> And implementations for these other languages are typically written in
> what?  Hm?

Machine code for Ada. Hm?

- Ed

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[CBFalconer]

Ed Falis wrote:
> 
> Micah Cowan wrote:
> 
> > > The point is that if you look at the security bugs in Linux or Microsoft
> > > software they consists mainly of buffer overflow bugs. This comes from
> > > using languages such as C and C++ which allow buffer overflow due to
> > > their design. Other languages eliminate this problem to a large extent.
> >
> > And implementations for these other languages are typically written in
> > what?  Hm?
> 
> Machine code for Ada. Hm?

I think you will find that GNU Ada is written in GNU Ada.  I KNOW
that PascalP is written in Pascal.  Neither is totally bug free,
although at time of release they were IMHO free of *known*
undocumented bugs.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@XXXXworldnet.att.net)
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:uce@ftc.gov  (for spambots to harvest)

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Albert van der Horst]

In article <3B693DE4.C3B42E03@yahoo.com>,
CBFalconer  <cbfalconer@worldnet.att.net> wrote:
><SNIP>
>
>I think you will find that GNU Ada is written in GNU Ada.  I KNOW
>that PascalP is written in Pascal.  Neither is totally bug free,
>although at time of release they were IMHO free of *known*
>undocumented bugs.

You mean *none* of the unknown bugs where documented?
That is really surprising!

Albert.
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
albert@spenarnc.xs4all.nl     http://home.hccnet.nl/a.w.m.van.der.horst

Re: How Ada could have prevented the Red Code distributed denial of

[Larry Kilgallen]

In article <GHpu7E.4np.1.spenarn@spenarnc.xs4all.nl>, albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> In article <3B693DE4.C3B42E03@yahoo.com>,
> CBFalconer  <cbfalconer@worldnet.att.net> wrote:
>><SNIP>
>>
>>I think you will find that GNU Ada is written in GNU Ada.  I KNOW
>>that PascalP is written in Pascal.  Neither is totally bug free,
>>although at time of release they were IMHO free of *known*
>>undocumented bugs.
> 
> You mean *none* of the unknown bugs where documented?

No, I think the meaning is "None of the known bugs are undocumented".
There is an important distinction between "documented" and "fixed".
As the time for release approaches, it is often better to document
a bug than to fix it (depending on severity).  That which we change,
we break, and in the end game there may be insufficient testing for
side effects of the last few changes.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Richard Bos]

cross@augusta.math.psu.edu (Dan Cross) wrote:

> In article <Xz%97.2632$B37.106689@news1.rdc1.bc.home.com>,
> Kaz Kylheku <kaz@ashi.footprints.net> wrote:
> >>Chain saw guards - not needed, just use them properly!
> >>Seat belts - not needed, just drive properly!
> >
> >Can you drive improperly or saw improperly because of the presence of
> >safety features?
> 
> Sure you can!  But the incidences of people chopping off their fingers
> or being thrown through windshields went way down once chainsaw guards
> and seat belts came into widespread use.

Yes, and the seat belt actually nicely illustrates Kaz's point.

Immediately after the seat belt was introduced, the number of fatalities
in accidents plummeted.

The years after, the number slowly rose again, because drivers adapted
to the new safety level seat belts provided and were willing to take
risks they wouldn't have taken without them.

The nature of the fatalities have changed, yes. Nowadays, it's mostly
innocent bystanders that get killed, not the driver that flies through
the windscreen.

Richard

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Dan Cross]

In article <3b690498.1111845720@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>Yes, and the seat belt actually nicely illustrates Kaz's point.
>
>Immediately after the seat belt was introduced, the number of fatalities
>in accidents plummeted.
>
>The years after, the number slowly rose again, because drivers adapted
>to the new safety level seat belts provided and were willing to take
>risks they wouldn't have taken without them.

Yes, but would the average car driver buy a car without seat belts now?
Assuming the answer is, ``no...'' why would the average programmer choose
to use a programming language with seat-belt like features?

>The nature of the fatalities have changed, yes. Nowadays, it's mostly
>innocent bystanders that get killed, not the driver that flies through
>the windscreen.

Very sad, but undoubtedly true.  :-(  I consider myself very lucky to
live in a place where I don't have to use a car to get anywhere (New
York City).

Going back to programming, can we guess that as the number of programming
related defects goes down, the number of design related defects rises?  Or
is it that we're no longer hiding those design related defects behind our
programming errors?

	- Dan C.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Daniel Fischer]

begin followup ("Dan Cross" <cross@augusta.math.psu.edu>)

> Going back to programming, can we guess that as the number of
> programming related defects goes down, the number of design related
> defects rises?

Yes. Proof of concept: Java. :)

> Or is it that we're no longer hiding those design related defects behind
> our programming errors?

Don't think so. The more possible programming related defects you need to
consider, the more you think about your design.


Daniel

-- 
IMO, anyway.
end  message by (Daniel Fischer <dan@gueldenland.de>)
clc FAQ:    http://www.eskimo.com/~scs/C-faq/top.html
08/02	Our Lady of Los Angeles in Costa Rica

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Dan Cross]

In article <made-on-a-macintosh-969204-20460@usenet.l1t.lt>,
Daniel Fischer <dan@gueldenland.de> wrote:
>> Or is it that we're no longer hiding those design related defects behind
>> our programming errors?
>
>Don't think so. The more possible programming related defects you need to
>consider, the more you think about your design.

Hmm.  But as the minutia that we have to deal with goes away as
programming becomes more abstract, we are freed to concentrate more on
the design.  I'd have thought that worrying about the programming
related defects took up so much time there was little left to worry
about the design.  Though on the other hand, one can see that if
something is really hard to implement, folks will think really hard
about how to make it easier (and hence less error prone).

Maybe the problem is that as our ability to deal with complexity goes
up, we feel compelled to build more complex systems ``because we
can.''  In other words, it's a two edged sword.

	- Dan C.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Dan Cross wrote:
> 
> In article <made-on-a-macintosh-969204-20460@usenet.l1t.lt>,
> Daniel Fischer <dan@gueldenland.de> wrote:
> >> Or is it that we're no longer hiding those design related defects behind
> >> our programming errors?
> >
> >Don't think so. The more possible programming related defects you need to
> >consider, the more you think about your design.
> 
> Hmm.  But as the minutia that we have to deal with goes away as
> programming becomes more abstract, we are freed to concentrate more on
> the design.  I'd have thought that worrying about the programming
> related defects took up so much time there was little left to worry
> about the design.  Though on the other hand, one can see that if
> something is really hard to implement, folks will think really hard
> about how to make it easier (and hence less error prone).
> 
> Maybe the problem is that as our ability to deal with complexity goes
> up, we feel compelled to build more complex systems ``because we
> can.''  In other words, it's a two edged sword.
> 
>         - Dan C.

The level of "complexity" is _indeed_ the root of a lot of difficulty
in software today. There have been a number of attemps to solve this, 
some of which include:

  - BASIC
  - COBOL
  - PL/I
  - PASCAL
  - 4GL
  - Java

etc.

Each approach has their own ups and downs.

Yet, if your program was as simple as :

  01 OPEN FILE #1, "X"
  02 WRITE #1,"A"
  03 CLOSE FILE #1

it's simplicity is such that you can say, "I know it is perfect" (which
of course assumes the compiler/interpreter is perfect). As you move
beyond this level of complexity, it becomes increasingly difficult to
vouch for the correctness of the program under all circumstances.

The difficulty today is that software is not only larger (especially with
GUI), but some of it has become distributed with CORBA/DCE/COM/DCOM/etc.

Still, as developers, we are tasked with producing "quality software".

Ada is an excellent language tool, which helps improve upon
the quality of the software, while making the code "simpler",
and more "readable".  The quality/readability aspects have been 
addressed here, so, let's look at how it can simplify your life :

  Array bounds as you need them (C/C++ and Java still insist that you start
      at zero and work up). (PL/I could have different bounds too).

  No need to know pointer context (C/C++ require obj.attr or obj->attr
      depending upon what you have). The Ada compiler knows hows to do
      obj.attr regardless of the context.

  Records with discriminants : Ada lets you define records (structs) with
      varying size, according to the discriminant. C/C++ still must define
      a char [1], and purposely work outside the array bounds to suit. For
      an example, look at man msgsnd(2) (msgsnd(3) on BSD). They use the

      struct {
         long mtype;    /* message type */
         char mtext[1]; /* body of message */
      }

      If the size of your message text varies, you must fake it in C/C++,
      by allocating for the largest message, but abusing the bounds of the
      mtext[] member array. It turns out however, this can be dealt with
      in C/C++ by defining a specific instance of this structure with the
      max size for mtext[].

      _However_, if you had to include a 3rd member
      in this message, then you'd be forced to fake it, with ugly
      pointer magic, probably hidden inside of a macro to keep the
      code readable. For example, if you added a process ID in the 
      message:

      struct {
         long mtype;    /* message type */
         char mtext[1]; /* body of message */
         pid_t PID;     /* Process ID */
      }

      You'd now have to have a fixed mtext[] array size, or through some
      pointer magic, locate member PID.

  String form of enumerated values (in Ada), upon demand. In C/C++, you 
      must provide this for yourself. (ie. if you have C enum { Idle,
         Waiting, Running } e; How do you print out the string
         representation of e?)

  Array slice assignment and comparison (in Ada). In C/C++, you must code
      this for yourself, in loops etc. In Ada, you can assign array slices
      as in A_Array(1..3) := B_Array(5..7). In C/C++, you'd have to depend
      upon a function, or code a loop.

  Attributes in Ada (like My_Array'Length). In C/C++ you must mess with the
      sizeof operator (which can fool you with physical size instead of logical
      size), or code it yourself with macros (constants in Java).

  And Ada does much much more ;-)

There are simply a number of other little things that Ada does for you, 
which _simplifies_ your job as a developer. The point of this post is that
Ada helps in the direction of _simplifying_ your software development.

Combine that with a rigorous check of your code, you come up with a good
and powerful combination. Given that it's *free* (GNAT), all you need to
do is install it and try it.

Act now, while the Internet supplies last! ;-)

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bart.Vanhauwaert]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
>   Array bounds as you need them (C/C++ and Java still insist that you start
>       at zero and work up). (PL/I could have different bounds too).

This seems a minor advantage. In fact, I consider the uniformity
and advantage. Less possibility for off by one errors (did they start
at 0 or at 1? I am too lazy to check, let's just assume 1, etc)

>   No need to know pointer context (C/C++ require obj.attr or obj->attr
>       depending upon what you have). The Ada compiler knows hows to do
>       obj.attr regardless of the context.

Again, minor advantage. The compiler will warn you if you make mistakes.

>   Records with discriminants : Ada lets you define records (structs) with
>       varying size, according to the discriminant. C/C++ still must define
>       a char [1], and purposely work outside the array bounds to suit. For
>       an example, look at man msgsnd(2) (msgsnd(3) on BSD). They use the

In C++ you just use virtual member funcs. Or template functions if
speed is primordial. Easier, cleaner. Comparable mechanisms exist
in C.

>   String form of enumerated values (in Ada), upon demand. In C/C++, you 
>       must provide this for yourself. (ie. if you have C enum { Idle,
>          Waiting, Running } e; How do you print out the string
>          representation of e?)

Minor advantage. Totally ofset by the fact that serious software needs
internationalization anyway. If really needed, a gross #define hack
does the trick.

>   Array slice assignment and comparison (in Ada). In C/C++, you must code
>       this for yourself, in loops etc. In Ada, you can assign array slices
>       as in A_Array(1..3) := B_Array(5..7). In C/C++, you'd have to depend
>       upon a function, or code a loop.

Read up on the STL. It does that and more (like sticking a transformation
in between, copying from stdin directly to a slice, etc...)

>   Attributes in Ada (like My_Array'Length). In C/C++ you must mess with the
>       sizeof operator (which can fool you with physical size instead of logical
>       size), or code it yourself with macros (constants in Java).

Again, this seems mostly syntactical sugar. I don't understand the
physical/logical argument. If you mean padding, it is a well
understood phenomena. Anyone writing programs where padding matters,
knows enough to understand the documentation of his/her compiler
to straighten such issues out.

>   And Ada does much much more ;-)

How'd I go about creating a M$-alike desktop application (after all,
there is no arguing that is the largest market for software)?
Time gains of being able to directly (re)use large codebases that
certain (popular) platforms offer for example are more
important than all your arguments mentioned above. 
While I am certain that Ada has bindings for some platform
functionality, I am also certain they are not as complete as
those for C/C++.

Sure, if you are doing a defense job, it could be that the platform
you need is better developed in Ada. But proposing Ada now as
_the_ best solution on the basis of some (not very convincing imho)
situations where ada simplifies development, is plain and simple
taking one's wishes for granted.

cu bart

-- 
http://www.irule.be/bvh/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Ted Dennison]

In article <q22nk9.r1p.ln@10.0.0.2>, Bart.Vanhauwaert@nowhere.be says...
>
>Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
>>   Array bounds as you need them (C/C++ and Java still insist that you start
>>       at zero and work up). (PL/I could have different bounds too).
>
>This seems a minor advantage. In fact, I consider the uniformity
>and advantage. Less possibility for off by one errors (did they start
>at 0 or at 1? I am too lazy to check, let's just assume 1, etc)

That's why we use 'First and 'Last in Ada. So we have both the advantage you
quote, and the one you discount. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Marin David Condic]

And don't forget 'Range - very useful for "for" loops. And the same thing
works with multiple dimensions as in Some_Array'First (1) or
Some_Array'Range (2) or Some_Array'Length (N). What is really useful here is
that if you avoid coding things with hard references into the array, you can
pretty much leave the code untouched if/when you make any changes to the
sizes/indexes of the array. It gets even more useful when trying to write
generic array utilities or utilities that can deal with a *slice* of an
array. (Like: "Some_Procedure (Some_Array (6..23)) ;" - if the internals use
the attributes, it works nicely for any slice.)

In general the attributes are *very* handy because they provide information
that the compiler just automatically knows about and can use so that things
are not hard coded. To some extent you can do this in C/C++ by defining your
own constants or functions but ultimately a change to the data structure
means revisiting this code - possibly missing something. With Ada, a change
to the data structure should just take care of itself as long as you use the
attributes. (Of course, there isn't anything to stop you from hard-coding
things in Ada as well - but if you hose it up, at least you'll get a
compiletime or runtime error letting you know you did that.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:JzUb7.1653$NJ6.5860@www.newsranger.com...
>
> That's why we use 'First and 'Last in Ada. So we have both the advantage
you
> quote, and the one you discount. :-)
>

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bart.Vanhauwaert]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
> And don't forget 'Range - very useful for "for" loops. And the same thing
> works with multiple dimensions as in Some_Array'First (1) or
> Some_Array'Range (2) or Some_Array'Length (N). What is really useful here is
> that if you avoid coding things with hard references into the array, you can
> pretty much leave the code untouched if/when you make any changes to the
> sizes/indexes of the array. It gets even more useful when trying to write
> generic array utilities or utilities that can deal with a *slice* of an
> array. (Like: "Some_Procedure (Some_Array (6..23)) ;" - if the internals use
> the attributes, it works nicely for any slice.)

I am not really sure where this is fundamentally different from

for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)
	...

and

Some_Procedure(v.begin()+6, v.begin()+23);

and

v.size()

(Btw, as an application programmar, I get supicious whenever I see
a fixed size array. It means some arbitrary limit (or arbitrary
waste of resources) that some user eventually will stumble upon and
of course complain)

cu bart

-- 
http://www.irule.be/bvh/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Ted Dennison]

In article <apesk9.env.ln@10.0.0.2>, Bart.Vanhauwaert@nowhere.be says...
>
>Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
>> And don't forget 'Range - very useful for "for" loops. And the same thing

>I am not really sure where this is fundamentally different from
>
>for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)

That's actually pretty close, and seems to have all the benifits Marin was
touting. Its a shame I've never seen it "in the wild". :-)

There are some differences, though:

o  In the Ada version, "i" would not be assignable within the loop. This allows
the compiler to optimize things a lot more easily. 
o  I'm not to sure how C++ compilers implement calls to the iterator's "++"
operator, but it looks like a function call to me (perhaps even a dispatching
one?). The Ada for loop is going to use whatever hardware incrementation method
is fastest (assuming it doesn't just unroll some or all of the loop). In a tight
loop, the speed difference could be significant.
o  In the Ada version, the range of "i" is much more likely (almost certian
actually) to be discernable at compile time. Again, this allows the compiler to
optimize things a lot more easily. It also means that there won't be extra code
(and time) used to figure out the bounds at runtime.

The first issue is due to the fact that C went for maximum "hackability", and
thus doesn't have a constrained loop form for optimizing compilers to work with.
The last two are due to C leaving type safety issues up to library writers,
rather than properly addressing them in the language itself.

>(Btw, as an application programmar, I get supicious whenever I see
>a fixed size array. It means some arbitrary limit (or arbitrary
>waste of resources) that some user eventually will stumble upon and
>of course complain)

Actually, in Ada a fixed sized array does not always mean that. You can go
figure out what the size needs to be (at startup time or runtime), and then
perform the array declaration.

Also, remember that all of us are not application programmers. Marin and I are
systems programmers. I get quite suspicous of any *dynamic* data structure, as
its liable to consume time that I don't have to spare. Sometimes the time
*variability* of dynamic memory operations can be a big problem too (eg: when
updating a display, your time between updates has to be *exact*, or things look
weird). There's a trade-off involved with choosing any particular data
structure, and you have to balance your requirements against those trade-offs.
Arbitrary limits may be annoying for your average GUI app, but device drivers
and OS kernels (especially RTOS's) are chock full of them, and for good reason. 

Systems software is pretty much what this thread is about. In particular, one
*shouldn't* have to balance safety and execution speed as much as C++ system
programmers have to. Given the choice, many systems programmers are naturally
going to decide that they just can't take the speed hit of using the safe
abtract classes (and some are just perverse and prefer not to either way). By
putting type safety in the language, rather than pushing it off into tacked-on
libraries, Ada allows safe code that can optimize much better and run much
faster than equivalently safe C++ code. With a little work, it can even be
faster than *unsafe* C++ code (due to issues like less aliasing and the
too-flexible for loop I mentioned above).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bart.Vanhauwaert]

Ted Dennison <dennison@telepath.com> wrote:
>>for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)
> That's actually pretty close, and seems to have all the benifits Marin was
> touting. Its a shame I've never seen it "in the wild". :-)

I use it all the time (and love it)

> o  In the Ada version, "i" would not be assignable within the loop. This allows
> the compiler to optimize things a lot more easily. 

I am not really sure, why do you think that?

> o  I'm not to sure how C++ compilers implement calls to the iterator's "++"
> operator, but it looks like a function call to me (perhaps even a dispatching
> one?). The Ada for loop is going to use whatever hardware incrementation method
> is fastest (assuming it doesn't just unroll some or all of the loop). In a tight
> loop, the speed difference could be significant.

This depends on the implementation of the STL of course. It certainly is
not a virtual function call. std::vector<What>::iterator is a either a
wrapper around an int or a pointer to What. In both cases it translates
to just pre-incrementing the pointer or the integer. Modern compilers
have no trouble optimizing this.

> o  In the Ada version, the range of "i" is much more likely (almost certian
> actually) to be discernable at compile time. Again, this allows the compiler to
> optimize things a lot more easily. It also means that there won't be extra code
> (and time) used to figure out the bounds at runtime.

True. Some compilers don't hoist the call to v.end(). If you feel
pathetic about it you can always do it by hand. I think for a non-trivial
loop it is lost in the noise. Better compilers optimize this completly
away of course.

> Also, remember that all of us are not application programmers. Marin and I are
> systems programmers. I get quite suspicous of any *dynamic* data structure, as

I guess that's why you use Ada and I use C++? Best tool for the job
and all that?

> its liable to consume time that I don't have to spare. Sometimes the time
> *variability* of dynamic memory operations can be a big problem too (eg: when
> updating a display, your time between updates has to be *exact*, or things look
> weird). There's a trade-off involved with choosing any particular data
> structure, and you have to balance your requirements against those trade-offs.
> Arbitrary limits may be annoying for your average GUI app, but device drivers
> and OS kernels (especially RTOS's) are chock full of them, and for good reason. 

Probably. I don't know anything about system programming.

However, predictability is achievable in C++ just as well as in C.
For example all containers in the STL have an allocator as template
argument. So if you need predictable memory allocation you can
override the standard allocator and for example use memory from a
pre-allocated pool.

> Systems software is pretty much what this thread is about. In particular, one

Is it? I approached this thread from the application programming side.

cu bart

-- 
http://www.irule.be/bvh/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Bart.Vanhauwaert@nowhere.be wrote:
> Ted Dennison <dennison@telepath.com> wrote:
> >>for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)
> > That's actually pretty close, and seems to have all the benifits Marin was
> > touting. Its a shame I've never seen it "in the wild". :-)
> 
> I use it all the time (and love it)

Don't forget that in Ada, there are Booch components that sports 
iterator types that can be used in a manner that is similar. But
I think the thing that has been lost in all of this is that you
are comparing C++ _STL_ features with Ada _language_ features.

But C++ users always want to appeal to the STL to solve the C++ 
language deficiencies.

If you compared _language_ for _language_, you'd have a lot 
of minuses in the C++ camp. Language for language, Ada95 is
unmistakably "better" in almost all ways that I can think of 
(there are a few minor exceptions of course).

However, if we then compared C++ _STL_ with 
_Booch components_, you'd have some pluses, and Ada would have 
some pluses, but some minuses.  I suppose the
biggest _minus_ on the Ada side is that _Booch components_
are not part of any _standard_ or official Ada offering AFAIK.

(I will also plead ignorance of the Ada83 booch components library).

I suppose you could imagine the next 5 years running something 
like this:

   C++ camp improves upon compilers and/or language to improve
      quality at compile time, insert optional runtime checks.

   Ada95 camp improves upon and maybe standardizes upon an
      official version of the Booch components.

> > o  I'm not to sure how C++ compilers implement calls to the iterator's "++"
> > operator, but it looks like a function call to me (perhaps even a dispatching
> > one?). The Ada for loop is going to use whatever hardware incrementation method
> > is fastest (assuming it doesn't just unroll some or all of the loop). In a tight
> > loop, the speed difference could be significant.
> 
> This depends on the implementation of the STL of course. It certainly is
> not a virtual function call. std::vector<What>::iterator is a either a
> wrapper around an int or a pointer to What. In both cases it translates
> to just pre-incrementing the pointer or the integer. Modern compilers
> have no trouble optimizing this.

It is true that unless they did something wacky like make it virtual, the
C++ inline ++ operator is usually cheap.

The biggest difficiency here though is that C++ programmers must use STL
containers to buy any sort of safety. It is simply unnecessary to resort
to a Vector container in Ada for safety. Naked arrays in Ada have
all the protection and convenience one could ask for.  It is also 
easier to read the code that uses it, and hence makes code audits 
much easier.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bertrand Augereau]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 779 bytes --]


"Warren W. Gay VE3WWG" <ve3wwg@home.com> a �crit dans le message news:
3B73337F.862F8D93@home.com...
> Bart.Vanhauwaert@nowhere.be wrote:
> > Ted Dennison <dennison@telepath.com> wrote:
> > >>for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)
> > > That's actually pretty close, and seems to have all the benifits Marin
was
> > > touting. Its a shame I've never seen it "in the wild". :-)
> >
> > I use it all the time (and love it)
>
> Don't forget that in Ada, there are Booch components that sports
> iterator types that can be used in a manner that is similar. But
> I think the thing that has been lost in all of this is that you
> are comparing C++ _STL_ features with Ada _language_ features.
>

But STL *IS PART OF* C++ language, no?
It is *standard*.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Bertrand Augereau wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> a �crit dans le message news:
> 3B73337F.862F8D93@home.com...
> > Bart.Vanhauwaert@nowhere.be wrote:
> > > Ted Dennison <dennison@telepath.com> wrote:
> > > >>for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)
> > > > That's actually pretty close, and seems to have all the benifits Marin
> was
> > > > touting. Its a shame I've never seen it "in the wild". :-)
> > >
> > > I use it all the time (and love it)
> >
> > Don't forget that in Ada, there are Booch components that sports
> > iterator types that can be used in a manner that is similar. But
> > I think the thing that has been lost in all of this is that you
> > are comparing C++ _STL_ features with Ada _language_ features.
> >
> 
> But STL *IS PART OF* C++ language, no?
> It is *standard*.

It _uses_ the C++ language, but does not define it or it's semantics.
It is even a standard _yes_, and it might even be that it must be
included with the C++ compiler, but it is _not_ the C++ language.
The C++ language existed long before STL came along, and even though
it enhances it's use etc. etc. etc., I would just be repeating myself
again if I said that the STL is not the _language_ or an extension
of it. It is a class _library_, which uses the C++ language, which
includes using the C++ template [language] _facilities_. But a language 
it is not.

But if you insist on calling sheep as goats, and goats as sheep, 
then I give up. You win.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Chris Wolfe]

[c.l.c trimmed, as the STL's got boo-all to do with them]

"Warren W. Gay VE3WWG" wrote:
> 
> Bertrand Augereau wrote:
[snip]
> > But STL *IS PART OF* C++ language, no?
> > It is *standard*.
> 
> It _uses_ the C++ language, but does not define it or it's semantics.
> It is even a standard _yes_, and it might even be that it must be
> included with the C++ compiler, but it is _not_ the C++ language.
> The C++ language existed long before STL came along, and even though
> it enhances it's use etc. etc. etc., I would just be repeating myself
> again if I said that the STL is not the _language_ or an extension
> of it. It is a class _library_, which uses the C++ language, which
> includes using the C++ template [language] _facilities_. But a language
> it is not.
> 
> But if you insist on calling sheep as goats, and goats as sheep,
> then I give up. You win.

On the basis of that tirade Natural, Positive, String and virtually
every other useful object provided by Ada is not the Ada language. If
it's required by the standard, it's part of the language.

I do not believe (and I may well get corrected on this) that the STL
templates are anywhere prevented from being implemented as compiler
internals (i.e. not as a library). Quite a few optimizing C and C++
compilers will generate common library calls directly within the
program (via special handling, rather than by inlining the library
code). So where do you want to draw this magical line between
language definition and core libraries?

If you keep insisting those goats are sheep you are going to lose by
global plonking...

Chris

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B7C79FA.89E62321@globetrotter.qc.ca>, Chris Wolfe says...
>On the basis of that tirade Natural, Positive, String and virtually
>every other useful object provided by Ada is not the Ada language. If
>it's required by the standard, it's part of the language.

First off, I agree totally with the intent of your objection. STL is in the
standard reference manual, and can thus be counted on to be part of any
conformant compiler as much as "int" can. Unfortunately, you can't count on any
one C++ compiler actually being conformant, like you can with Ada, but that's
another flamewar...

But I should point out that there is a very real difference between the language
defined types (numbers, records, arrays, etc), and stuff in libraries in an
annex somewhere. The stl is *built on* C++, rather than being an integral part
of it. Unless your compiler writers were *very* clever, that's going to cause
some overhead. Either way, you've still got that temptingly terse unsafe
language-defined array support enshrined in the standard, begging to be
(ab)used.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Chris Wolfe]

Ted Dennison wrote:
[snip]
> But I should point out that there is a very real difference between the language
> defined types (numbers, records, arrays, etc), and stuff in libraries in an
> annex somewhere. The stl is *built on* C++, rather than being an integral part
> of it. Unless your compiler writers were *very* clever, that's going to cause
> some overhead.

If it's in the standard, it's an integral part. Either the STL is
part of the C++ language, or the Predefined Language Environment is
not part of Ada. Excluding both would be pretty stupid, so I shall
continue ignoring that "definition".

I doesn't takes a genius to produce special cases where common STL
calls are treated as language elements. Once the compiler writer
decides to build it in, it's mostly identifying which calls the
compiler can't inline automatically, plus grunt-work. I am assuming
that Ada compilers support at least parts of the Predefined Language
Environment in this form (notice: from an annex).

> Either way, you've still got that temptingly terse unsafe
> language-defined array support enshrined in the standard, begging to be
> (ab)used.

I don't believe anyone claimed safe programming in C++ was for the
forgetful or the clueless. There are languages better suited for
those folks, and Ada does not really qualify either.

Anyway, unless someone has something interesting to contribute I'm
going to go back to ignoring this thread. Hopefully until it dies...

Chris

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Richard Bos]

cross@augusta.math.psu.edu (Dan Cross) wrote:

> In article <3b690498.1111845720@news.worldonline.nl>,
> Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> >The years after, the number slowly rose again, because drivers adapted
> >to the new safety level seat belts provided and were willing to take
> >risks they wouldn't have taken without them.
> 
> Yes, but would the average car driver buy a car without seat belts now?
> Assuming the answer is, ``no...'' why would the average programmer choose
> to use a programming language with seat-belt like features?

They couldn't, now, but more than a few simply refuse to use them.

But a more close analogy: how many people choose to drive only on 50Mph
roads, because it's safer? Bounds checking _does_ come at a price, you
know.

> Going back to programming, can we guess that as the number of programming
> related defects goes down, the number of design related defects rises?

Since the design is part of the programming (or should be!), I can only
answer "Mu!".

Richard

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Dan Cross]

In article <3b6a453c.1193942215@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>> Yes, but would the average car driver buy a car without seat belts now?
>> Assuming the answer is, ``no...'' why would the average programmer choose
>> to use a programming language with seat-belt like features?
>
>They couldn't, now, but more than a few simply refuse to use them.

Indeed they don't; much the same way as many programmers don't make use
of safer tools.  Most of the time, it doesn't matter, but sometimes it
*really* does.

>But a more close analogy: how many people choose to drive only on 50Mph
>roads, because it's safer? Bounds checking _does_ come at a price, you
>know.

Sure it comes at a price, but this is where the analogy breaks down;
often bounds checking can be done in such a manner that it's almost
impercetible in terms of the performance difference compared to
non-bounds checked systems.  Ie, a few percentage points difference.
Maybe the difference is between going 70MPH and 63MPH or so.

A personal anecdote about people driving too fast: I was skateboarding
across 3rd avenue in Manhattan a couple of weeks ago, and a guy driving
a car ran a red light and ran into me.  Luckily, he had managed to slam
on the breaks, and I had managed to swerve, so by the time he hit me,
it was just a ``tap.''  However, I was pretty furious, and aquanted the
driver of the car with that fact more than adequately.

He said he had had to swerve to avoid rear-ending a car (I don't know
if careening through a pedestrian walkway at an intersection is the
best course of action to contemplate in avoiding a car-to-car accident,
though!).

Anyway, he was obviously pretty shaken up, and no harm was done, so we
both went our seperate ways.  However, I had started to think that here
was a good example of someone who wasn't really paying attention to
what they were doing (why should anyone be going fast enough that they
have to swerve to avoid rear-ending a car at a light in New York
City?), and were placing their own convenience ahead of the general
safety, with possibly disasterous results.  Luckily, I had managed to
swerve, but had someone else been in my place who wasn't able to get
out of the way before he mostly stopped (say I had been an elderly
person), someone could have gotten seriously injured or killed.

Is one's convenience, or some modicum of additional speed, really worth
the risk?  A parallel can be drawn to software.  We often hear people
saying, ``oh, I don't want to deal with bounds checking because it'll
slow down my program.''  My answer to this is always, ``well, does that
matter?  Does your program need to be that fast?  And how much will it
really slow things down?''  Often, the answers are surprising mundane
and support bounds checking.

Wasn't it Henry Spencer who used to say, ``that tin god, efficiency'' ?

>> Going back to programming, can we guess that as the number of programming
>> related defects goes down, the number of design related defects rises?
>
>Since the design is part of the programming (or should be!), I can only
>answer "Mu!".

Huh?  ``Design as you go'' is rarely a good strategy; you should always
have some idea how to start before applying fingers to keyboard.  Even
methods such as `extreme programming' (which emphisizes step-wise
refinement of both design and code) doesn't just start with ``int
main(...)'' and go from there; you start out with a pretty good idea of
what you want to accomplish and how you want to do it.

	- Dan C.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Preben Randhol]

On 3 Aug 2001 11:05:25 -0400, Dan Cross wrote:

> Is one's convenience, or some modicum of additional speed, really worth
> the risk?  A parallel can be drawn to software.  We often hear people
> saying, ``oh, I don't want to deal with bounds checking because it'll
> slow down my program.''  My answer to this is always, ``well, does that
> matter?  Does your program need to be that fast?  And how much will it
> really slow things down?''  Often, the answers are surprising mundane
> and support bounds checking.

I think that the old macho thinking is still lingering around. Like a
car enthusiast want to have his head down in the engine all day changing
screws etc to make the engine perfect, though never actually travel
somewhere with it. A "real" programmer[*] won't fiddle with high level
languages as his programs will not run as fast as if one did it in
assembly or pseudo-assembly (read C). Never mind that it takes a lot
longer to develope.

I heard a story once about a computer project at a university. The
students had a task to solve and they could choose their language. The
girls mainly chose Lisp or some other high level language and got the
task done quickly and efficiently returning working code. The boys
mainly chose C and few actually managed to complete the task in time or
at all.

So I fear that sometimes the macho gets in the way of the solution.

For other experience on this look at: 
   http://www.acm.org/sigada/conf/sigada99/mccormick.html

If an app uses 10 seconds more to startup or 5% longer to complete a
task, where is the hurt? I am pretty sure that if you also put into
the equation all that time that is spent after a program has crashed
etc.. you will find that you don't loose time on software with better
quality.

Preben

[*] Not a real programmer, only somebody who thinks "High level
languages are for sissies, let me bit flick!"

-- 
�Don't use C;  In my opinion,  C is a library programming language
 not an app programming language.�  - Owen Taylor (GTK+ developer)

Use Ada 95, a free language. More info at http://www.adapower.com/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Mark Wilden]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9mlqp3.56q.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> If an app uses 10 seconds more to startup or 5% longer to complete a
> task, where is the hurt? I am pretty sure that if you also put into
> the equation all that time that is spent after a program has crashed
> etc.. you will find that you don't loose time on software with better
> quality.

Just a comment on the "5% longer" figure. That might not seem like much, but
if you're talking about a process that takes three days to complete, saving
5% means you get your results over three hours sooner. In other words, a
small percentage of a large amount can be significant.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Preben Randhol]

On Fri, 3 Aug 2001 12:37:30 -0700, Mark Wilden wrote:
> Just a comment on the "5% longer" figure. That might not seem like much, but
> if you're talking about a process that takes three days to complete, saving
> 5% means you get your results over three hours sooner. In other words, a
> small percentage of a large amount can be significant.

5% was just an arbitrary figure, probably much too high. But what about
you do 5 of these 3 days calculations and then realise that there is a
trivial error (one that using a different language would have prevented)
in your code which makes the resulted calculation wrong?  If I remember
correctly this happened in one of the clients of distributed.net. How
are you going to get back these 360 hours?

I'll like a parachute to open always rather than that it opens 1ms
faster, but at occasions fail to work althoghter.

Preben
-- 
�Don't use C;  In my opinion,  C is a library programming language
 not an app programming language.�  - Owen Taylor (GTK+ developer)

Use Ada 95, a free language. More info at http://www.adapower.com/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Mark Wilden]

randhol+abuse@pvv.org (Preben Randhol) wrote in message news:<slrn9mnbld.8ak.randhol+abuse@kiuk0156.chembio.ntnu.no>...
> 
> I'll like a parachute to open always rather than that it opens 1ms
> faster, but at occasions fail to work althoghter.

So would I, but this has nothing to do with the point I made.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Preben Randhol]

On 6 Aug 2001 09:48:33 -0700, Mark Wilden wrote:
> randhol+abuse@pvv.org (Preben Randhol) wrote in message news:<slrn9mnbld.8ak.randhol+abuse@kiuk0156.chembio.ntnu.no>...
>> 
>> I'll like a parachute to open always rather than that it opens 1ms
>> faster, but at occasions fail to work althoghter.
> 
> So would I, but this has nothing to do with the point I made.

Yes it was. Ada in itself is not a slower language. Though the extra
security of runtime checks like boundary checks will cost a bit. C
doesn't have this. Your point was that speed was more important than the
extra security. I don't agree.

Preben
-- 
�Don't use C;  In my opinion,  C is a library programming language
 not an app programming language.�  - Owen Taylor (GTK+ developer)

Use Ada 95, a free language. More info at http://www.adapower.com/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Preben Randhol wrote:
> On 6 Aug 2001 09:48:33 -0700, Mark Wilden wrote:
> > randhol+abuse@pvv.org (Preben Randhol) wrote in message news:<slrn9mnbld.8ak.randhol+abuse@kiuk0156.chembio.ntnu.no>...
> >>
> >> I'll like a parachute to open always rather than that it opens 1ms
> >> faster, but at occasions fail to work althoghter.
> >
> > So would I, but this has nothing to do with the point I made.
> 
> Yes it was. Ada in itself is not a slower language. Though the extra
> security of runtime checks like boundary checks will cost a bit. C
> doesn't have this. Your point was that speed was more important than the
> extra security. I don't agree.

Not only that, C/C++ _cannot_ provide those checks. To include those
checks, requires that someone provide them, whether they be assert()
macros or some other means. This means that it is also possible that
the assert macros can be incorrectly coded, and never triggered when
intended.

The STL argument does not hold water either. If you look through any
C++ project, somewhere, someplace, there will be naked references to
at least char arrays, and possibly arrays of ints and other types.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Chris Wolfe]

"Warren W. Gay VE3WWG" wrote:
> 
> Preben Randhol wrote:
[snip]
> > Yes it was. Ada in itself is not a slower language. Though the extra
> > security of runtime checks like boundary checks will cost a bit. C
> > doesn't have this. Your point was that speed was more important than the
> > extra security. I don't agree.
> 
> Not only that, C/C++ _cannot_ provide those checks. To include those
> checks, requires that someone provide them, whether they be assert()
> macros or some other means. This means that it is also possible that
> the assert macros can be incorrectly coded, and never triggered when
> intended.

Egad... my compiler's fictional! I suppose C and C++ _cannot_
provide garbage collection either? Or automatic serialization, or
range-checked arithmetic types, or anything else that the
compiler writer decides to include.

It does not require any overwhelming work to convert an Ada
program directly into a functionally identical C++ program using
appropriate (non-standard) templates. Amazingly these templates
also tend to spawn safe versions of the standard C functions.
What was that drivel about pipe again?

I have no issues with propaganda, but it being blatantly wrong is
somewhat annoying.

Chris

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Chris Wolfe wrote:
> "Warren W. Gay VE3WWG" wrote:
> > Preben Randhol wrote:
> [snip]
> > > Yes it was. Ada in itself is not a slower language. Though the extra
> > > security of runtime checks like boundary checks will cost a bit. C
> > > doesn't have this. Your point was that speed was more important than the
> > > extra security. I don't agree.
> >
> > Not only that, C/C++ _cannot_ provide those checks. To include those
> > checks, requires that someone provide them, whether they be assert()
> > macros or some other means. This means that it is also possible that
> > the assert macros can be incorrectly coded, and never triggered when
> > intended.
> 
> Egad... my compiler's fictional! I suppose C and C++ _cannot_
> provide garbage collection either? Or automatic serialization, or
> range-checked arithmetic types, or anything else that the
> compiler writer decides to include.

Well, tell us just _what_ compiler you are using, and just how it
addresses the identified issues. You have done neither :)

> It does not require any overwhelming work to convert an Ada
> program directly into a functionally identical C++ program using
> appropriate (non-standard) templates. 

We're we talking about doing "conversions"? Let's stick to the
discussion here, if you want to respond to "points made".

> Amazingly these templates
> also tend to spawn safe versions of the standard C functions.
> What was that drivel about pipe again?

Spawn? Templates?  Show us how this solves the problems identified,
and maybe we'll be enlightened. Again.. no substance to your post :)

> I have no issues with propaganda, but it being blatantly wrong is
> somewhat annoying.

I challenge you to show us just "how blatantly wrong" I am. I can
handle being wrong. Just ask my wife ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Chris Wolfe]

"Warren W. Gay VE3WWG" wrote:
>
> > Egad... my compiler's fictional! I suppose C and C++ _cannot_
> > provide garbage collection either? Or automatic serialization, or
> > range-checked arithmetic types, or anything else that the
> > compiler writer decides to include.
> 
> Well, tell us just _what_ compiler you are using, and just how it
> addresses the identified issues. You have done neither :)

You stated: "C/C++ _cannot_ provide [runtime checks like boundary
checks]"
This is false. The compiler I am using is a proprietary one, but
with a search on Google for C AND "array bounds checking" I found
a list of public ones (including a patch for GCC).

Automatic serialization, range-checked arithmetic types and
garbage collection are a sampling of other features I have run
across in C-like compilers.

> > It does not require any overwhelming work to convert an Ada
> > program directly into a functionally identical C++ program using
> > appropriate (non-standard) templates.
> 
> We're we talking about doing "conversions"? Let's stick to the
> discussion here, if you want to respond to "points made".

By definition, C++ (or C, or assembler) is capable of expressing
any concept that Ada is capable of.

My assertion is that the capabilities of C++ make possible a
library that is semantically identical to Ada's. Hence, using
appropriate (non-standard) templates, it does not require
overwhelming work to convert an Ada program directly into a
functionally identical C++ program.

> > Amazingly these templates
> > also tend to spawn safe versions of the standard C functions.
> > What was that drivel about pipe again?
> 
> Spawn? Templates?  Show us how this solves the problems identified,
> and maybe we'll be enlightened. Again.. no substance to your post :)

// Implement safe completely dynamic array here
template <class T> class Array { ... };

class Posix
{
// ...
  // Safe pipe, as Array checks bounds
  int pipe(Array<int> &);
// ...
};

> > I have no issues with propaganda, but it being blatantly wrong is
> > somewhat annoying.
> 
> I challenge you to show us just "how blatantly wrong" I am. I can
> handle being wrong. Just ask my wife ;-)

There is only one possible 'Ada is better' argument: That
something in the Ada libraries can not be provided cleanly by
C++.

As was observed earlier, C++ is far from uniform. The STL string
classes do not bounds check, Microsoft's CString checks in debug
mode, and the string class I am using as part of my utils lib
checks unless explicitly switched into no-checking mode.

Chris

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Chris Wolfe wrote:
> "Warren W. Gay VE3WWG" wrote:
> >
> > > Egad... my compiler's fictional! I suppose C and C++ _cannot_
> > > provide garbage collection either? Or automatic serialization, or
> > > range-checked arithmetic types, or anything else that the
> > > compiler writer decides to include.
> >
> > Well, tell us just _what_ compiler you are using, and just how it
> > addresses the identified issues. You have done neither :)
> 
> You stated: "C/C++ _cannot_ provide [runtime checks like boundary
> checks]"
> This is false. The compiler I am using is a proprietary one, but..

He he, but the one you are _using_ - does it provide array bounds
checking?  Does it throw an exception when your integer or unsigned
type overflows? I expect not. 

> with a search on Google for C AND "array bounds checking" I found
> a list of public ones (including a patch for GCC).

That's just peachy. But a sampling of the population of C++
users using these, ahem, extensions, are likely to be a small portion
of all C++ users.

I suppose you're simply offended by the "_cannot_" remark. Yes, I
suppose that it _is_ possible for a C++ compiler to generate runtime
checks, and even do some limited compile time static checks. But that
is not the general experience.

> Automatic serialization, range-checked arithmetic types and
> garbage collection are a sampling of other features I have run
> across in C-like compilers.

"Run across" is different than saying "I can depend upon ____". In
Ada, you can depend upon the features mentioned. If not, it ain't 
Ada. Ada has a compiler validation suite for this purpose.

> > > It does not require any overwhelming work to convert an Ada
> > > program directly into a functionally identical C++ program using
> > > appropriate (non-standard) templates.
> >
> > We're we talking about doing "conversions"? Let's stick to the
> > discussion here, if you want to respond to "points made".
> 
> By definition, C++ (or C, or assembler) is capable of expressing
> any concept that Ada is capable of.
> 
> My assertion is that the capabilities of C++ make possible a
> library that is semantically identical to Ada's. Hence, using
> appropriate (non-standard) templates, it does not require
> overwhelming work to convert an Ada program directly into a
> functionally identical C++ program.

This is another "take my word for it testimonial here". I will
grant that C++ is a general purpose language, and is quite capable of 
solving any general compuational problem. Ada likewise can solve the
same set of problems. But was not where the discussion was.

We were discussing how well a given language and compiler can solve
problems. Not that they could. That is already a given, since there'd
be no need to compare them if this were not already true.

> > > Amazingly these templates
> > > also tend to spawn safe versions of the standard C functions.
> > > What was that drivel about pipe again?
> >
> > Spawn? Templates?  Show us how this solves the problems identified,
> > and maybe we'll be enlightened. Again.. no substance to your post :)

> // Implement safe completely dynamic array here
> template <class T> class Array { ... };

Ok, you can build classes to do array work. In Ada, this is totally
unnecessary for the same level of safety (the safety is inherent
in the language).  But my point was, that you won't use this array
when interfacing to pipe(2). You can, and _you_ might, but a lot
of C++ people will not.

> class Posix
> {
> // ...
>   // Safe pipe, as Array checks bounds
>   int pipe(Array<int> &);
> // ...
> };

This very well and good. You defined a class to interface with the
pipe(2) call. Now, if every C++ programmer _always_ did it this way
(or some safe way),
and _always_ implemented it correctly, for all POSIX interfaces 
that were used, that present this type of problem, 
_then_ you might have a point with this solution.

But in reality, if I were to audit any C++ shop for interfaces to the O/S
or even to 3rd party libraries, I can safely bet that I'll find
naked arrays all over the place (even outside of your "interface
classes"). I'll grant you, that a few careful shops may be vigilant
about avoiding these issues, but it will _not_ be the _norm_.

There are at least two other problems that remain unsolved:

  1. There is no inherent overflow checking (not important in
     the pipe(2) case, but may be in other API calls).

  2. You now have to prove that your Class Posix is fault free
     before you put it on an aircraft or in a medical instrument.
     It has unsafe refs to naked arrays and does not have overflow
     or divide by zero checks.
     Proving safety is not as easy as it looks. The "I have extensively
     tested it" is not a convincing argument on its own. Additionally,
     C++ is notoriously difficult to read (translate: "code audit")

> There is only one possible 'Ada is better' argument: That
> something in the Ada libraries can not be provided cleanly by
> C++.

What makes this assertion true? You say it is, but don't provide any
evidence of this.  There are things I don't like about some of the
Ada packages, but I can say the same thing about C or C++. I don't
see this as a distinguishing feature for the purpose of this 
discussion. We were discussing safety inherent in the Ada language,
as compared to C++ (and C), not library features.

You know that it's easy to defend what you know and use. It's
harder to say "maybe there's something there that I should at 
least know more about."

I know this well, because I came from a position
similar to the one you're holding now. I finally bought a book,
installed GNAT, to find out what the "truth of the matter was".
I mean, I _really_ investigated -- ie. started writing code in it.
Lots of it!

I came away from the experience "converted", much to Ken Burtch's
surprise (he had for quite some time expounded the virtues of Ada,
which I confess, I sneered at).

One of my sneers was "C programmers don't need training wheels", 
which is how I rated "array bounds checks". Well, it turns out,
if these be "training wheels", then they are a good thing. The
reason is that the training wheels keep programmers from taking
corners more sharply than they they should ;-)

> As was observed earlier, C++ is far from uniform. The STL string
> classes do not bounds check, Microsoft's CString checks in debug
> mode, and the string class I am using as part of my utils lib
> checks unless explicitly switched into no-checking mode.
> 
> Chris

Chris, I really don't expect you to take my word for the strengths
of Ada. Nobody should. I didn't. However, I hope that there is
enough here, and by others, that you someday find the time to
install GNAT and get a book -- and actually use it for a while
in a recreational sense. ;-) I mean it.

I've tried to point out some practical issues to you. I've not
done the best possible job of this, but it helps if you keep
an open mind. Install GNAT.. try it. If you give it an honest
try and you still hate it, then at least you have informed 
reasons for it. But beware... you might just learn to 
like it ;-)

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Chris Wolfe]

"Warren W. Gay VE3WWG" wrote:
> Chris Wolfe wrote:
> > You stated: "C/C++ _cannot_ provide [runtime checks like boundary
> > checks]"
> > This is false. The compiler I am using is a proprietary one, but..
> 
> He he, but the one you are _using_ - does it provide array bounds
> checking?

Yes, hence its usage as an example of a compiler that supports
array bounds checking.

The arithmetic checking I use is provided via my inline Integer
template. The compiler is quite happy optimizing out the checking
on constants.

> I suppose you're simply offended by the "_cannot_" remark. Yes, I
> suppose that it _is_ possible for a C++ compiler to generate runtime
> checks, and even do some limited compile time static checks. But that
> is not the general experience.

Yes, I am offended by a statement that (insert stereotype here).

So why not compare _comparable_ things: like a C++ compiler and
library designed with safety in mind against Ada. Rather than a
family of languages and libraries designed with ease of
implementation and speed in mind? Ah right, that would leave the
choice to person preference in syntax and flexibility.

> Ok, you can build classes to do array work. In Ada, this is totally
> unnecessary for the same level of safety (the safety is inherent
> in the language).

The compiler inserts the code provided by the Array template into
all your code automatically. I wear a seat belt, those who choose
to do otherwise...

> But my point was, that you won't use this array
> when interfacing to pipe(2). You can, and _you_ might, but a lot
> of C++ people will not.

So we do the Ada thing: throw away the flexibility of the
language to force everyone to play safe. In case you missed it,
most C++ compiler also provide support for inline assembler: A)
if I need it, I can get it. B) if I don't need it, I can stick
with the safer stuff. Ada has a very different philosophy.

>   2. You now have to prove that your Class Posix is fault free
>      before you put it on an aircraft or in a medical instrument.

Duh, and this was somehow skipped when producing the Ada
libraries? I somehow fail to believe that Ada circumvents bugs in
the functions provided by my operating system.

> You know that it's easy to defend what you know and use. It's
> harder to say "maybe there's something there that I should at
> least know more about."

When coming from a VB and Pascal background Ada looked like a
natural extension. Fortunately I looked at C one day and said
"maybe there's something there that I should at least know more
about." The led to C++, which led to moving many of the useful
Ada concepts into classes and templates. Flexibility, conciseness
and wide spread use. Oh yes, and my seat belt.

Chris

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B71C74E.505A8753@globetrotter.qc.ca>, Chris Wolfe says...
>So why not compare _comparable_ things: like a C++ compiler and
>library designed with safety in mind against Ada. Rather than a

Because this thread is about OS's and the C++ dialects which they have been
implemented in, vs. (standard) Ada. Clearly your wonderful non-standard dialect
of C++ was not used either for the system software in question. Perhaps it would
have been an equally good idea to use it, but that's not what the thread is
about.

>So we do the Ada thing: throw away the flexibility of the
>language to force everyone to play safe. In case you missed it,
>most C++ compiler also provide support for inline assembler: A)
>if I need it, I can get it. B) if I don't need it, I can stick
>with the safer stuff. Ada has a very different philosophy.

That's a odd complaint. Ada's just as flexible as C. You just have to announce
to the compiler (and not so incidently, the human source code reader) when you
are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
opposed to "most" C++ compilers) has support for inline assembler. Its actually
in the standard. The Ada philosopy is indeed quite different from C's but its
not quite what you seem to think it is.

>>   2. You now have to prove that your Class Posix is fault free
>>      before you put it on an aircraft or in a medical instrument.
>
>Duh, and this was somehow skipped when producing the Ada
>libraries? I somehow fail to believe that Ada circumvents bugs in
>the functions provided by my operating system.

He probably shouldn't have brought this up, as it confuses just about everyone
who isn't familiar with safety-critical software. Debugging software and proving
it correct are two *very* different things. There's a whole lot of theory behind
safety critical software and software correctness proofs that you really have to
study for a while to understand. Bringing it into a discussion with folks who
are unfamiliar with it is just going to cause a lot of confusion.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Martin Ambuhl]

Ted Dennison wrote:
> 
> In article <3B71C74E.505A8753@globetrotter.qc.ca>, Chris Wolfe says...
> >So why not compare _comparable_ things: like a C++ compiler and
> >library designed with safety in mind against Ada. Rather than a
> 
> Because this thread is about OS's and the C++ dialects which they have been
> implemented in, vs. (standard) Ada. Clearly your wonderful non-standard dialect
> of C++ was not used either for the system software in question. Perhaps it would
> have been an equally good idea to use it, but that's not what the thread is
> about.
> 
> >So we do the Ada thing: throw away the flexibility of the
> >language to force everyone to play safe. In case you missed it,
> >most C++ compiler also provide support for inline assembler: A)
> >if I need it, I can get it. B) if I don't need it, I can stick
> >with the safer stuff. Ada has a very different philosophy.
> 
> That's a odd complaint. Ada's just as flexible as C. You just have to announce
> to the compiler (and not so incidently, the human source code reader) when you
> are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its actually
> in the standard. The Ada philosopy is indeed quite different from C's but its
> not quite what you seem to think it is.
> 
> >>   2. You now have to prove that your Class Posix is fault free
> >>      before you put it on an aircraft or in a medical instrument.
> >
> >Duh, and this was somehow skipped when producing the Ada
> >libraries? I somehow fail to believe that Ada circumvents bugs in
> >the functions provided by my operating system.
> 
> He probably shouldn't have brought this up, as it confuses just about everyone
> who isn't familiar with safety-critical software. Debugging software and proving
> it correct are two *very* different things. There's a whole lot of theory behind
> safety critical software and software correctness proofs that you really have to
> study for a while to understand. Bringing it into a discussion with folks who
> are unfamiliar with it is just going to cause a lot of confusion.
> 

Taking your pronouncements as Gospel, I have removed comp.lang.c from
the Followup-To: list.  I suggest you do the same.

Re: How Ada could have prevented the Red Code distributed denial of

[cppwiz]

[Note: headers have been trimmed]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:Hoxc7.3953$NJ6.15706@www.newsranger.com...
> In article <3B71C74E.505A8753@globetrotter.qc.ca>, Chris Wolfe says...

<deleted>

> That's a odd complaint. Ada's just as flexible as C. You just have to
announce
> to the compiler (and not so incidently, the human source code reader) when
you
> are doing something unsafe, but its not prevented. Also *every* Ada
compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its
actually
> in the standard...

The C++ standard guarantees that there is at least a platform in place for
inline assembler.
I don't see how its realistically possible to make a promise stronger than
that.

Unless I missed something, the Ada standard provides a similar guarantee for
inline assembler.

In both cases, the implementation can conform to the standard by providing
no inline assembler functionality.

Re: How Ada could have prevented the Red Code distributed denial of

[Stanley R. Allen]

Ted Dennison wrote:

> *every* Ada compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its actually
> in the standard.

Ada does have a standard for inline assembler language (package System.Machine_Code).
But it is one of those features which, according to the standard, is not required
to be implemented for a 'conforming' implementation of Ada.  See

http://www.adahome.com/rm95/rm9x-01-01-03.html   (paragraph 10)
http://www.adahome.com/rm95/rm9x-13-08.html      (paragraph 8)

--
Stanley Allen
mailto:Stanley_R_Allen-NR@Raytheon.com

Re: How Ada could have prevented the Red Code distributed denial of

[Larry Kilgallen]

In article <Hoxc7.3953$NJ6.15706@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:

> are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its actually
> in the standard.

Certainly you don't mean 13.8(8), which says:

	An implementation is not required to provide package
	System.Machine_Code.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <c78BbJ9nURZD@eisner.encompasserve.org>, Larry Kilgallen says...
>
>In article <Hoxc7.3953$NJ6.15706@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
>
>> are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
>> opposed to "most" C++ compilers) has support for inline assembler. Its actually
>> in the standard.
>
>Certainly you don't mean 13.8(8), which says:
>
>	An implementation is not required to provide package
>	System.Machine_Code.

Doh! You're right (and he didn't even include the "An implementation may place
restrictions on code_statements" part). So in fact, the situation is pretty much
the same as C++, except that there is a standard way to do it if it *is*
supported. Not that that matters much, since the machine code itself is hardly
going to be portable...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bart.Vanhauwaert]

Dan Cross <cross@augusta.math.psu.edu> wrote:
>>The average car driver does not buy a car limited to 20km/hour.
> As has been pointed out in the thread, Ada performance is comparable
> to C given the right compiler (ie, a very good Ada compiler compares
> favorably to a very good C compiler).

Well bring on your sources (note: that's source in the journalistic
sense).

> Besides, I certainly think it would be within the scope of the thread
> for you to post examples and sources where this was true (note: that's
> source in the journalistic sense).  So....  Feel free to do so.
> Otherwise, what you say is just hearsay, I'm afraid.

Look for my other post in this thread. Easy of (re)use of components
for major dekstop platforms is for me the most relevant part of the
trade-off.

cu bart

-- 
http://www.irule.be/bvh/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Dan Cross]

In article <t0kok9.1p4.ln@10.0.0.2>,  <Bart.Vanhauwaert@nowhere.be> wrote:
>Well bring on your sources (note: that's source in the journalistic
>sense).

They weren't my sources.  :-)  Whoever posted them is free to point to
their earlier post or otherwise make the information available again.

>> Besides, I certainly think it would be within the scope of the thread
>> for you to post examples and sources where this was true (note: that's
>> source in the journalistic sense).  So....  Feel free to do so.
>> Otherwise, what you say is just hearsay, I'm afraid.
>
>Look for my other post in this thread. Easy of (re)use of components
>for major dekstop platforms is for me the most relevant part of the
>trade-off.

Then you miss the point entirely.

	- Dan C.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bart.Vanhauwaert]

Dan Cross <cross@augusta.math.psu.edu> wrote:
>>Look for my other post in this thread. Easy of (re)use of components
>>for major dekstop platforms is for me the most relevant part of the
>>trade-off.
> Then you miss the point entirely.

Which point?

cu bart

-- 
http://www.irule.be/bvh/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Dan Cross]

In article <5drpk9.l0e.ln@10.0.0.2>,  <Bart.Vanhauwaert@nowhere.be> wrote:
>Which point?

The point that those desktop components could and should be built to
a higher level of quality than they currently are, perhaps using better
tools.

If all you want to do is perpetuate the status quo, then by all means
continue doing what you're doing.

	- Dan C.

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bart.Vanhauwaert]

Dan Cross <cross@augusta.math.psu.edu> wrote:
> The point that those desktop components could and should be built to
> a higher level of quality than they currently are, perhaps using better
> tools.

I am not yet convinced that desktop components would be dramatically
better if they where written in Ada. Some of the major points brought
forward in this thread (bounds checking, ...) currently exist in
Java. Java software is not generally of a higher quality than 
equivalent C/C++ software.

> If all you want to do is perpetuate the status quo, then by all means
> continue doing what you're doing.

Well, I personally am satisfied with the quality of the tools for C++
(and the language itself). They are not perfect, but generally they are
good enough. Enough that 99% of the failures of the software
I write happen because of mistakes by me (the programmer). Other tools
wouldn't matter.

cu bart

-- 
http://www.irule.be/bvh/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Bart.Vanhauwaert@nowhere.be wrote:
> Dan Cross <cross@augusta.math.psu.edu> wrote:
> > The point that those desktop components could and should be built to
> > a higher level of quality than they currently are, perhaps using better
> > tools.
> 
> I am not yet convinced that desktop components would be dramatically
> better if they where written in Ada. Some of the major points brought
> forward in this thread (bounds checking, ...) currently exist in
> Java. Java software is not generally of a higher quality than
> equivalent C/C++ software.

Like BASIC (of any dialect), Java suffers from having a lot of stuff
checked at runtime. That is not where you want to find the errors.
You want the developers to find the problems (compile time when 
possible), rather than once it is in the users hands. 

> > If all you want to do is perpetuate the status quo, then by all means
> > continue doing what you're doing.
> 
> Well, I personally am satisfied with the quality of the tools for C++
> (and the language itself). They are not perfect, but generally they are
> good enough. Enough that 99% of the failures of the software
> I write happen because of mistakes by me (the programmer). Other tools
> wouldn't matter.
> 
> cu bart

Here is that Microsoft argument "good enough" again. Software can be
better, but people in general, just don't seem to care *sigh*. Thankfully,
nobody accepts this argument for medical instruments and flight gear. Hey,
maybe I'll get lucky and some C++ program will drop a zero from my mortgage!
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Bart.Vanhauwaert]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> Here is that Microsoft argument "good enough" again. Software can be
> better, but people in general, just don't seem to care *sigh*. Thankfully,
> nobody accepts this argument for medical instruments and flight gear. Hey,
> maybe I'll get lucky and some C++ program will drop a zero from my mortgage!

Don't be silly. Nothing is perfect. Any serious decision is a
trade-off. You can pretend that better software is something that
comes painless without extra effort, but that is just untrue.
'Good enough' is a perfectly valid argument which ALSO applies
to medical instruments and flight gear. My girl-friend is a doctor
and I know first hand that good enough is always applied in the 
medical field.

The same holds for other possibly life-threatening situations.

The construction of my home is good enough but there is always the
change it crummbles, my reaction speed is good enough but there is
always the change I didn't see a car making an inexpected turn,
airport security is good enough but there will always be the
change of a terrorist attack, etc.. etc..

If you really think good enough is not good enough you shouldn't
be driving a car, taking a plane, visiting a doctor or staying 
in a building. That path leads to paranoia.

cu bart

-- 
http://www.irule.be/bvh/

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Bart.Vanhauwaert@nowhere.be wrote:
> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> > Here is that Microsoft argument "good enough" again. Software can be
> > better, but people in general, just don't seem to care *sigh*. Thankfully,
> > nobody accepts this argument for medical instruments and flight gear. Hey,
> > maybe I'll get lucky and some C++ program will drop a zero from my mortgage!
> 
> Don't be silly. Nothing is perfect. Any serious decision is a
> trade-off. 

You are obviously not showing a sense of humour about this...

You are correct that there are trade-offs. I guess what annoys 
me is just how low the standard is for "good enough" in so 
many circles. Microsoft's being one of the most offensive.

Let's just leave it at that ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B73378B.EF7E2C10@home.com>, Warren W. Gay VE3WWG says...
>
>Bart.Vanhauwaert@nowhere.be wrote:
>> Don't be silly. Nothing is perfect. Any serious decision is a
>> trade-off. 
>
>You are correct that there are trade-offs. I guess what annoys 
>me is just how low the standard is for "good enough" in so 
>many circles. Microsoft's being one of the most offensive.

As near as I can tell, they actually take software design theory *far* more
seriously at Microsoft that most folks give them credit for. I think the issue
here is that Microsoft happens to be the world's biggest believers in the
time-tested "Worse is Better" design philosophy. (see
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html ). This is
great for Microsoft, but no so great for things that need to be carefully
designed in, like security and reliablity. But then, they are a publicly-traded
company, so "great for Microsoft" trumps all other considerations for them. :-)

A particularly relevent excerpt: 
---
A further benefit of the worse-is-better philosophy is that the programmer is
conditioned to sacrifice some safety, convenience, and hassle...
---

Note that in this particular context, "programmer"="user". (They were talking
about programming languages and OS calls.).

another relevant part:
--- 
The lesson to be learned from this is that it is often undesirable to go for the
right thing first. It is better to get half of the right thing available so that
it spreads like a virus. Once people are hooked on it, take the time to improve
it to 90% of the right thing.
----

Again, great for Microsoft, crappy for security.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Warren W. Gay VE3WWG]

Ted Dennison wrote:
> In article <3B73378B.EF7E2C10@home.com>, Warren W. Gay VE3WWG says...
> >Bart.Vanhauwaert@nowhere.be wrote:
> >> Don't be silly. Nothing is perfect. Any serious decision is a
> >> trade-off.
> >
> >You are correct that there are trade-offs. I guess what annoys
> >me is just how low the standard is for "good enough" in so
> >many circles. Microsoft's being one of the most offensive.
> 
> As near as I can tell, they actually take software design theory *far* more
> seriously at Microsoft that most folks give them credit for.

You may be right about this, but it's hard for us on the outside
to see much evidence of it ;-)

> I think the issue
> here is that Microsoft happens to be the world's biggest believers in the
> time-tested "Worse is Better" design philosophy. (see
> http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html ). This is
> great for Microsoft, but no so great for things that need to be carefully
> designed in, like security and reliablity. But then, they are a publicly-traded
> company, so "great for Microsoft" trumps all other considerations for them. :-)

Quite true. This is why they also don't give much consideration to fixing
problems on their platforms. They don't have to care, so it is easy for
them to say "just reinstall your software".  Instead, they'll offer some
small tweak in the next version (for you to buy), that somehow placates
the poor locked in customer..

> Again, great for Microsoft, crappy for security.

I think this is one _downfall_ that will eventually force them to put
more "quality" in. Before the Windows platform had TCP/IP access, this
was of no concern to them, and they pretty much could ignore security
(what a simple life it is, when we can do that on any platform ;-)

Now that M$ has to keep coming out with rapid patches to holes that 
keep being exploited, they may finally get to the point some day where
they may want to improve their image on this point, and treat security
with greater care.

But it is likely going to require more competition before they'll 
bring themselves to this point, so one keeps hoping that Apple 
will get their act together as competition. On the server side, I do
believe that they are feeling some pressure from Linux in this
regard, though Red Hat (by default) has been pretty lame in 
security, from what I can see.

In this vein, I'd love to see sendmail and bind/named done in 
Ada.  That would not solve all of the security issues, but at
least would eliminate most, if not all of the code exploit 
issues.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of

[David Starner]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B73FEA5.D4B46E89@home.com...
> In this vein, I'd love to see sendmail and bind/named done in
> Ada.  That would not solve all of the security issues, but at
> least would eliminate most, if not all of the code exploit
> issues.

I'd be more inclined to trust something battle-tested than something new,
even if the new program was written in Ada. For a lot of the stuff, Ada
would just turn a remote exploit into DOS (program failure by uncaught
exception), which is an improvement, but it's still a bug and a problem.

--
David Starner - dstarner98@aasaa.ofe.org
"The pig -- belongs -- to _all_ mankind!" - Invader Zim

Re: How Ada could have prevented the Red Code distributed denial of

[Warren W. Gay VE3WWG]

David Starner wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3B73FEA5.D4B46E89@home.com...
> > In this vein, I'd love to see sendmail and bind/named done in
> > Ada.  That would not solve all of the security issues, but at
> > least would eliminate most, if not all of the code exploit
> > issues.
> 
> I'd be more inclined to trust something battle-tested than something new,
> even if the new program was written in Ada. For a lot of the stuff, Ada
> would just turn a remote exploit into DOS (program failure by uncaught
> exception), which is an improvement, but it's still a bug and a problem.

My concern David, is that for every bug fixed in the C/C++ versions of
these servers, how many more of the same are still unnoticed, and yet to
be exploited. I agree that a new untested version of the same servers
would bring out new problems initially. But it wasn't that long ago
that Bind 8 just came out, which IIRC, was "rewritten" anyway. My point
is that rewrites would have/will be - better in Ada. The current
state of the art seems to be to "battle-harden" the C/C++ exploits,
for the most part.

A newly written server done in Ada, would ramp up in security
quickly, and all of us could then focus on a smaller subset of the
remaining issues, IMHO.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of

[Warren W. Gay VE3WWG]

I just re-read what you wrote, and realized I misunderstood
the thrust of what you said.. so I'll re-reply, since I can't
retract the prior post.

David Starner wrote:
> 
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3B73FEA5.D4B46E89@home.com...
> > In this vein, I'd love to see sendmail and bind/named done in
> > Ada.  That would not solve all of the security issues, but at
> > least would eliminate most, if not all of the code exploit
> > issues.
> 
> I'd be more inclined to trust something battle-tested than something new,
> even if the new program was written in Ada. For a lot of the stuff, Ada
> would just turn a remote exploit into DOS (program failure by uncaught
> exception), which is an improvement, but it's still a bug and a problem.

This indeed is an _improvement_, while a "bug and a problem". However,
I would much prefer this mode of operation, because this means that
the problem will get more immediate attention for a _fix_.

To some extent, the same DOS aspects apply to C/C++ code (aborts). 
Where there is no "signal", it either "corrupts", "ignores" or runs
"exploit code". But raising exceptions in Ada will hopefully provide 
notice before your system is exploited.

That is my primary reason for wishing.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of service attack.

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

G>>    It can be, but it can also be an inline function, or a simple
>>call-through to the built in operator++, in both cases, any compiler
>
> Can it? In Ada at least, I understand that potentially dynamic-dispatching
> operations are really tough to inline. I suppose there could be something I
> don't know about C++ that gets rid of that issue. Is there?

The standard C++ container library does not use dynamic dispatching
for containers, it even suggests not to subclass them.  The container
library isn't very OOP.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <8766bxx9mu.fsf@deneb.enyo.de>, Florian Weimer says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> Can it? In Ada at least, I understand that potentially dynamic-dispatching
>> operations are really tough to inline. I suppose there could be something I
>> don't know about C++ that gets rid of that issue. Is there?
>
>The standard C++ container library does not use dynamic dispatching
>for containers, it even suggests not to subclass them.  The container
>library isn't very OOP.

Perhaps, but that would give it the ability to be inlined. So there is a postive
to that.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com