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

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

[Gautier Write-only-address]

Marin:

>Otherwise, Ada is a general purpose language like C or C++ & I'm not sure
>I'd agree that there is some problem space addressed by C or C++ that isn't
>fit for Ada as well. That's why I'm curious about where you think it 
>doesn't
>fit well.

I'm also curious, because that language unexpectedly fits
well in areas that its noisiest advocates have never touched!
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: Do not answer to sender address, visit the Web site!
    Ne r�pondez pas � l'exp�diteur, visitez le site ouaibe!



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

[Gautier Write-only-address]

> > Windows 98 ... a success of the pointer-to-buffer macro-assemblers.

>Please don't blame assembler for Win98.  And there is nothing wrong
>about using pointers to buffers.  The trouble starts when you misuse
>them.

I don't blame assembler (it is of course necessary in some parts,
and generally carefully programmed), but over-used macro-assembler.
At a certain scale in a project one should have a rich typing, e.g.
arrays - the true ones, with bounds.

G.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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.

[Martin Ambuhl]

raj wrote:

[Ada advocacy rant]

Ada advocacy belongs in Ada groups.  In comp.lang.c, comp.lang.c++, and
comp.lang.functional your crap is at best spam.  Perhaps Ada will teach you
how to cease being a troll.

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

[Daniel Fischer]

Hej,

- followup ("raj" <israelrt@optushome.com.au>)

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

Get a clue. :)


Daniel

-- 
IMO, anyway.
end  message by (Daniel Fischer <dan@gueldenland.de>)
` { } \ | [ ] ' ~    :) ;) :/ :( <-- insert as needed
clc FAQ:    http://www.eskimo.com/~scs/C-faq/top.html

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

[raj]

On Wed, 01 Aug 2001 07:01:13 +0200, "Daniel Fischer"
<dan@gueldenland.de> wrote:


>>  Win32 Buffer Overflows (Location, Exploitation and Prevention)
>   ~~~~~
>> 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.
>  ~~~
>Get a clue. :)

IIS servers run on Win32 systems....

IR Thomas
---------------------------------------------------



VI VI XIII
Roman Neighbour of the Beast

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

[Bart v Ingen Schenau]

raj wrote in message <97ffmt0ccpeqe2s34m88cik31ugojebltn@4ax.com>...
>On Wed, 01 Aug 2001 07:01:13 +0200, "Daniel Fischer"
><dan@gueldenland.de> wrote:
>
>
>>>  Win32 Buffer Overflows (Location, Exploitation and Prevention)
>>   ~~~~~
>>> 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.
>>  ~~~
>>Get a clue. :)
>
>IIS servers run on Win32 systems....


And your point is?

>
>IR Thomas


Bart v Ingen Schenau

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

[Lawrence Foard]

In article <made-on-a-macintosh-842059-11013@usenet.l1t.lt>,
Daniel Fischer <dan@gueldenland.de> wrote:
>> The buffer overflow occurs because of an old and well known bug in the C
>> libraries.

What does this have to do with C++? Any decent C++ programmer is using
std::string instead of char *. 

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

Or use of the features of a modern language like C++. Why restrict yourself
to obscure academic languages when a freely available and widely used
language does what you need?

The irony is that this problem starts in CS departments where kids are still
taught to use 'char *' instead of a string class.
-- 
     >>  Cold blooded attack on civilians - http://italia.indymedia.org <<
     Rave: Immanentization of the Eschaton in a Temporary Autonomous Zone.
      Real world computer problems solved without expensive buzzwords-
     My consulting resume http://www.farviolet.com/~entropy/resume2001.txt

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

[Matthias Blume]

Lawrence Foard wrote:
> 
> In article <made-on-a-macintosh-842059-11013@usenet.l1t.lt>,
> Daniel Fischer <dan@gueldenland.de> wrote:
> >> The buffer overflow occurs because of an old and well known bug in the C
> >> libraries.
> 
> What does this have to do with C++? Any decent C++ programmer is using
> std::string instead of char *.
> 
> >> 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.
> >  ~~~
> 
> Or use of the features of a modern language like C++. Why restrict yourself
> to obscure academic languages when a freely available and widely used
> language does what you need?

Because some of those obscure academic languages do not suck so badly.

> The irony is that this problem starts in CS departments where kids are still
> taught to use 'char *' instead of a string class.

The real irony is that the trouble is with CS departments where there is a choice
between using 'char *' and 'std::string' because it means that kids at such departments
are taught in C++.  C++ has to be about the worst choice for a teaching language.

Not to mention that real work gets done (and gets done well) in those obscure
academic languages, too.  They are hardly a "restriction".  In fact, if you had ever
given one of them a serious try, you might have found the experience liberating.

Regards,
Matthias

PS: By the way, the root of the problem is not fully solved by std::string.
Neither C nor C++ are "safe" languages and no amount of library hacking can make this
fact completely go away.  (Of course, Ada isn't safe either.)

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

[Kaz Kylheku]

In article <9k9ilv$jds$1@farviolet.com>, Lawrence Foard wrote:
>Or use of the features of a modern language like C++. Why restrict yourself
>to obscure academic languages when a freely available and widely used
>language does what you need?
>
>The irony is that this problem starts in CS departments where kids are still
>taught to use 'char *' instead of a string class.

Someone who is too clueless to correctly program in a language like C
should not be writing critical software in any language.  Low level data
representation details being taken care of, the programmer will simply
focus his or her lack of discipline and skill to some other area.

Saying that a better language will prevent errors is like saying that
installing video cameras in a neighborhood stops crime. That is a fallacy;
the crime is simply displaced to where there are no cameras.

Higher level languages are advantageous because of the greater ease
in which complex problems can be represented using fewer lines of
code that is more easily adapted to changing requirements. They don't
compensate for bad programming.

Also note that even with classes like std::string, C++ still provides
enough proverbial rope. For example, references can be bound to automatic
objects which are deleted when their statement block terminates, and
then those references can continue to be used. Uses of the ``safe''
operators new and delete can lead to memory leaks or the use of dangling
pointers. Even there there are pathatic pitfalls, like using delete []
with new or delete with new []. All kinds of pitfalls for the unwary exist
in C++ that are not inherited from C, like calling a virtual function
in a base class constructor, expecting to reach the derived one; adding
a new virtual function to a base class which happens to match the name
and type signature of an existing function in a derived class; deleting
through a base class that lacks a virtual destructor.

It's trivial to write a diagnostic-free program in this ``modern
language'' that contains horrible errors and is grossly non-portable.

Lastly, note that when you write real-world software in C++, you cannot
avoid interfacing with C libraries, which sometimes require you to use
C arrays. For instance, you can't read data from a socket directly into
a C++ buffer class. At some point you have to expose a low level buffer,
which is just a piece of memory, and pass the size of that buffer as
a separate parameter.

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

[Marin David Condic]

To combine two responses I've made elsewhere into one:

1) This is the "Any *competent* programmer would/wouldn't...." answer that I
do not find satisfying. We are all incompetent on any given hour of any
given day and we make simple, boneheaded mistakes that can be automatically
caught by a machine and prevented from escaping into the final product.
Whats wrong with that? Arguing that this is just going to force the bugs off
into some other area is a rather pessimistic view that treats bugs like they
were subject to gas laws - they can't be created or destroyed, only
relocated. ("In this house we obey the laws of thermodynamics!" --  Homer
Simpson :-) This seems to be absurd on the face of it. If that were true, we
should devote no effort whatsoever to bug prevention of any kind because it
would be wasted.

2) I personally did a study of defects on data collected over a ten year
timespan that compared defect rates when using Ada versus defect rates using
a number of other languages. The Ada projects had defect rates that were
lower by a factor of four. Saying that language of implementation has no
impact on the number of defects flies in the face of emperical evidence to
the contrary & I would ask that such claimants back that up with something
bordering on scientific evidence rather than rectal extraction. I have good
evidence that indicates languages *do* reduce errors by a very significant
amount. Not just my own study - try these links:

http://www2.dynamite.com.au/aebrain/ADACASE.HTM
http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp
http://www.rational.com/products/whitepapers/337.jsp

It may be that any given Ada program/programmer is going to be more
bug-ridden than some other program written in C/C++ by a "competent"
programmer. However, in the important business of making money for the
stockholders, I believe that we should use every technical advantage we can
get rather than relying on "competence" (which I doubt exists 100% of the
time in any of us). If a safer language like Ada exists and all other
considerations are equal, I'd think it was important to choose Ada and
reduce errors accordingly.

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/


"Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
news:BUZ97.2587$B37.101940@news1.rdc1.bc.home.com...
>
> Someone who is too clueless to correctly program in a language like C
> should not be writing critical software in any language.  Low level data
> representation details being taken care of, the programmer will simply
> focus his or her lack of discipline and skill to some other area.
>
> Saying that a better language will prevent errors is like saying that
> installing video cameras in a neighborhood stops crime. That is a fallacy;
> the crime is simply displaced to where there are no cameras.
>
> Higher level languages are advantageous because of the greater ease
> in which complex problems can be represented using fewer lines of
> code that is more easily adapted to changing requirements. They don't
> compensate for bad programming.
>

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

[CBFalconer]

Marin David Condic wrote:
> 
... snip ...
> 
> 2) I personally did a study of defects on data collected over a ten year
> timespan that compared defect rates when using Ada versus defect rates using
> a number of other languages. The Ada projects had defect rates that were
> lower by a factor of four. Saying that language of implementation has no
> impact on the number of defects flies in the face of emperical evidence to
> the contrary & I would ask that such claimants back that up with something
> bordering on scientific evidence rather than rectal extraction. I have good
> evidence that indicates languages *do* reduce errors by a very significant
> amount. Not just my own study - try these links:
> 
> http://www2.dynamite.com.au/aebrain/ADACASE.HTM
> http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp
> http://www.rational.com/products/whitepapers/337.jsp
> 
> It may be that any given Ada program/programmer is going to be more
> bug-ridden than some other program written in C/C++ by a "competent"
> programmer. However, in the important business of making money for the
> stockholders, I believe that we should use every technical advantage we can
> get rather than relying on "competence" (which I doubt exists 100% of the
> time in any of us). If a safer language like Ada exists and all other
> considerations are equal, I'd think it was important to choose Ada and
> reduce errors accordingly.

** PLEASE DO NOT top post **

I agree completely.  However, the presence of "better" languages
does not prevent anyone using other languages, for whatever
reasons.  The important thing is to recognize the flaws and
weaknesses of the chosen language, and to program in a defensive
manner.  In C (and other languages) this means using assert
statements and "can't happen" clauses in appropriate places.  It
also means NOT disabling run-time checks in languages that have
them (barring extreme performance needs).

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

[Tom Plunket]

Marin David Condic wrote:

> To combine two responses I've made elsewhere into one:
> 
> 1) This is the "Any *competent* programmer would/wouldn't...." answer that I
> do not find satisfying. We are all incompetent on any given hour of any
> given day and we make simple, boneheaded mistakes that can be automatically
> caught by a machine and prevented from escaping into the final product.

I don't think that was Kaz's point, although I could be wrong.  I
read it the same way at first, but then thought that maybe he
meant that "if someone is bad enough to not be able to program in
C/C++ safely (assuming they know the language at all), then they
probably shouldn't be doing mission-critical/life-critical
software in the first place!"

To this I agree; bad programmers can find work anywhere, they
don't need to be writing software that could kill me.  ;)


-tom!

-- 
Tom Plunket                                            tomas@fancy.org
PlayStation2/3D Studio geek
        "Our music is simple, it's totally fake.  It's done by
         machines 'cause they don't make mistakes."     -KMFDM

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

[Dave Adlam]

Tom Plunket wrote in message <20dmmtchgh62pgomgu8uj2f6vskag5po4v@4ax.com>...
>Marin David Condic wrote:
>
>> To combine two responses I've made elsewhere into one:
>>
>> 1) This is the "Any *competent* programmer would/wouldn't...." answer
that I
>> do not find satisfying. We are all incompetent on any given hour of any
>> given day and we make simple, boneheaded mistakes that can be
automatically
>> caught by a machine and prevented from escaping into the final product.
>
>I don't think that was Kaz's point, although I could be wrong.  I
>read it the same way at first, but then thought that maybe he
>meant that "if someone is bad enough to not be able to program in
>C/C++ safely (assuming they know the language at all), then they
>probably shouldn't be doing mission-critical/life-critical
>software in the first place!"
>
>To this I agree; bad programmers can find work anywhere, they
>don't need to be writing software that could kill me.  ;)
>
>
>-tom!
>
>--
>Tom Plunket                                            tomas@fancy.org
>PlayStation2/3D Studio geek
>        "Our music is simple, it's totally fake.  It's done by
>         machines 'cause they don't make mistakes."     -KMFDM

I have made an effort to learn C++, not to the level of being an expert, but
over several months, so not just a small effort.  I am not a "guru" at C++,
but knowing Ada and then learning C++, I would not choose to use C++ over
Ada for a safety related system where people could get injured or worse.
Yes, you can use design and coding techniques and/or tools to remove your
exposure to certain risks in C++, but the Ada language has many of these
features already built in so you can concentrate your effort where it should
be - on making the software safer (or if it is perfectly safe already, then
on further assurance activities to prove that it is safe).

Part of making a software based system is choosing the best tools for the
job.  This is something that is generally ignored these days in favour of
choosing the best tools for your CV!  Part of being a good programmer is
choosing the right tools for the job, or even the right tools for the right
part of the job - mixed language programming is possible!

Dave

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

[Richard Bos]

entropy@farviolet.com (Lawrence Foard) wrote:

> The irony is that this problem starts in CS departments where kids are still
> taught to use 'char *' instead of a string class.

No, the irony is that this problem does indeed start in CS departments,
because students[1] are taught in C++ and Ada, because these can be used
to teach safely and easily - which is good - but _not_ beyond that, into
"what can actually go wrong" territory - which is not good. The result
is too many students who leave not knowing about such things as possible
overflow, and thus don't know how to avoid it. In this way, languages
designed to promote safer programming actually promote unsafer
programming, by not promoting knowledge about what _is_ unsafe.

Richard

[1] Since when, btw, is a student a "kid"?

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

[Zoltan Somogyi]

info@hoekstra-uitgeverij.nl (Richard Bos) writes:
>[1] Since when, btw, is a student a "kid"?

Since about the time you turn 35 :-(

Zoltan Somogyi <zs@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science and Software Engineering, Univ. of Melbourne

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

[Richard Bos]

raj <israelrt@optushome.com.au> wrote:

HaaaHahahahaha....

You really are a complete imbecile, aren't you?

Go back to building big boys' toys for the President of the USA, and
leave the real programming to the real programmers.

Oh, and *plonk*.

Richard

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.

[Preben Randhol]

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.

-- 
Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette

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

[Karl Heinz Buchegger]

Preben Randhol wrote:
> 
> 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.

This comes from having programmers, which are unaware of what
they are doing.

> Other languages eliminate this problem to a large extent.

Better education and taking care of that problems helps a lot.
No need to change tools if you know how to work with them.

-- 
Karl Heinz Buchegger
kbuchegg@gascad.at

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

[Mark Lundquist]

"Karl Heinz Buchegger" <kbuchegg@gascad.at> wrote in message
news:3B682D53.5F32CDD1@gascad.at...
>
>
> Preben Randhol 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.
>
> This comes from having programmers, which are unaware of what
> they are doing.

True enough...

>
> > Other languages eliminate this problem to a large extent.
>
> Better education and taking care of that problems helps a lot.
> No need to change tools if you know how to work with them.

I understand the notion here, and I disagree.

You're right that people should understand the tools they work with.  But
the desire to change tools can come when you realize that the tool you're
using is a PAIN IN THE BUTT. :-)

Having to code my own array bounds checking would be a PitB.  The whole
point of computing is to automate things.  If it can be automated "for
free", then it should be.

I know about the string classes in C++.  But the cool thing about constraint
checking (including array bounds checking) in Ada is that the subtype
constraint rules work in such a way as to allow the compiler to optimize
away the checks when it can prove that they are not necessary.  You can only
get that if bounds checking is part of the language.

You might have a good tool, and you understand to work with it.  Then you
say, "I understand this tool, and it is good!".

Or you might have a crappy tool, and you understand it, too.  Then you say,
"I understand this tool, and it sucks!  Give me something better."  That's
what I'd say, anyway... :-)

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.

[Micah Cowan]

Ed Falis <efalis@mediaone.net> writes:

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

Fine.  And machine code doesn't have the potential for buffer overflow
problems, I presume?

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

[Ed Falis]

Micah Cowan wrote:
> 
> Ed Falis <efalis@mediaone.net> writes:
> 
> > 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?
> 
> Fine.  And machine code doesn't have the potential for buffer overflow
> problems, I presume?

Sorry, I misunderstood your initial remark.  Most Ada compilers are
written in Ada, and produce machine code.  I thought you were saying
they were implemented using C as an intermediate form.  You can get off
your high hobby horse now.

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

[Markus Mottl]

In comp.lang.functional Micah Cowan <micah@cowanbox.com> wrote:
> randhol+abuse@pvv.org (Preben Randhol) writes:
>> 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?

Any language that attempts to be called serious bootstraps
itself. Needless to say that the first compiler of a new language wasn't
written in the language itself, but the same holds true for C/C++...

> If you confine yourself

I prefer being confined by the compiler. It's usually less sleepy than I.

> "Modern" languages such as, oh, say Perl and Python,

"New": yes, "modern": no.

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

Simple: after years of bug chasing and endless support by legions of
users with bug reports, these issues have finally been solved...

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

A sound type system and an expressive language: good ideas for any
language ;)

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.

[Richard Heathfield]

Markus Mottl wrote:
> 
<snip>
> 
> Any language that attempts to be called serious bootstraps
> itself. Needless to say that the first compiler of a new language wasn't
> written in the language itself,

Just a small nit - there's nothing to stop you writing the first
compiler of a new language using an interpreter for that language. I
agree that you can't write the first *implementation* of a language in
itself, though. (Or at least, if you can, you are probably related to
Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
too.)

<snip>


-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

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

[Kaz Kylheku]

In article <3B688D21.810C5706@eton.powernet.co.uk>, Richard Heathfield wrote:
>Markus Mottl wrote:
>> 
><snip>
>> 
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,
>
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though. 

However, you can write that implementation in another language that is
arbitrarily close to that language. For example, an implementation of C
can be written in a variant of the C language which doesn't support the \v
escape sequence in character and string literals.  That implementation's
source code can then be corrected to use those literals where necessary,
so that for instance when it parses the \v sequence, the value that is
substituted is expressed as '\v'.

In this manner, you can start with some little language and then hack
more and more features into it, feeding them back into its own
source code.

>Or at least, if you can, you are probably related to
>Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
>too.

Or more likely, you *are* Thompson, Knuth, or Hofstadter. :)

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

[gregm]

In comp.lang.functional Kaz Kylheku <kaz@ashi.footprints.net> wrote:
:>Markus Mottl wrote:
:>> Any language that attempts to be called serious bootstraps
:>> itself. Needless to say that the first compiler of a new language wasn't
:>> written in the language itself,
: However, you can write that implementation in another language that is
: arbitrarily close to that language. For example, an implementation of C
: can be written in a variant of the C language which doesn't support the \v
: escape sequence in character and string literals.  That implementation's
: source code can then be corrected to use those literals where necessary,
: so that for instance when it parses the \v sequence, the value that is
: substituted is expressed as '\v'.

If you start with assembler, this process will lead to C very quickly. :)

-Greg

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

[Markus Mottl]

In comp.lang.functional Richard Heathfield <binary@eton.powernet.co.uk> wrote:
> Markus Mottl wrote:
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,

> Just a small nit - there's nothing to stop you writing the first
> compiler of a new language using an interpreter for that language. I
> agree that you can't write the first *implementation* of a language in
> itself, though. (Or at least, if you can, you are probably related to
> Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
> too.)

That's what I meant ("implementation" rather than "compiler"), but I was
thinking of languages that do not have interpreters (e.g. C), though in
theory interpreters are possible for any language.

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.

[Aaron Denney]

Markus Mottl <mottl@miss.wu-wien.ac.at> wrote:
> That's what I meant ("implementation" rather than "compiler"), but I was
> thinking of languages that do not have interpreters (e.g. C), though in
> theory interpreters are possible for any language.

C has a few interpreters for it, actually.  (Well, some are not quite C, or
don't implement everything.)

CINT, EiC, and ICI seem to be the most popular ones.  I've used one
in a job a few years back that was an extension language.  It was nice
because if the interpreted version wasn't fast enough, you could compile the
extension and load it as a dll. (I don't recall the name, and it was hacked by
the company to export our own bindings.  The only non-compliance I had found was
that adjacent string literals were not merged.)

-- 
Aaron Denney
-><-

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

[Markus Mottl]

In comp.lang.functional Aaron Denney <wnoise@ugcs.caltech.edu> wrote:
> CINT, EiC, and ICI seem to be the most popular ones.

I knew about CINT, which actually interprets C++ and is heavily used in
CERN's ROOT-project (data visualization). One can get pretty far with
those interpreters (at least with CINT). Still, I wouldn't say that
C/C++-interpreters are anywhere close to being commonly used. Other
languages lend themselves to interpretation much more easily.

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.

[CBFalconer]

Aaron Denney wrote:
> 
> Markus Mottl <mottl@miss.wu-wien.ac.at> wrote:
> > That's what I meant ("implementation" rather than "compiler"), but I was
> > thinking of languages that do not have interpreters (e.g. C), though in
> > theory interpreters are possible for any language.
> 
> C has a few interpreters for it, actually.  (Well, some are not quite C, or
> don't implement everything.)
> 
> CINT, EiC, and ICI seem to be the most popular ones.  I've used one
> in a job a few years back that was an extension language.  It was nice
> because if the interpreted version wasn't fast enough, you could compile the
> extension and load it as a dll. (I don't recall the name, and it was hacked by
> the company to export our own bindings.  The only non-compliance I had found was
> that adjacent string literals were not merged.)

I took a look at ch, from http://www.softintegration.com some time
ago.  It is not bad, but unfortunately fails in the acid test of
compiling valid C99 (or 89) code, largely due to the excessive use
of new reserved words.

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

[those who know me have no need of my name]

<9ka33g$b5h$4@bird.wu-wien.ac.at> divulged:

>I was thinking of languages that do not have interpreters (e.g. C), though
>in theory interpreters are possible for any language.

http://www.kd-dev.com/~eic/

-- 
okay, have a sig then

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

[Richard Heathfield]

Markus Mottl wrote:
> 
> [...] I was
> thinking of languages that do not have interpreters (e.g. C), though in
> theory interpreters are possible for any language.

As well as the other C interpreters people have mentioned in reply to
this, there was also one released by HiSoft for the Atari ST, which I
half-remember with great fondness.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

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

[Darren New]

> itself, though. (Or at least, if you can, you are probably related to
> Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
> too.)

Reminds me of a comment I saw in the Hermes distribution, something
along the lines of

"This is hand-compiled to bootstrap the compiler. Do not touch this. You
don't know what you're doing. Only Bill knows what he's doing. Bill is
God."

So yes, the other way is to hand-emulate the compiler you wrote to
figure out what it would generate. :-)

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
          Only a WIMP puts wallpaper on his desktop.

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

[Michael Rubenstein]

On Thu, 02 Aug 2001 00:13:37 +0100, Richard Heathfield
<binary@eton.powernet.co.uk> wrote:

>Markus Mottl wrote:
>> 
><snip>
>> 
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,
>
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though. (Or at least, if you can, you are probably related to
>Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
>too.)

In fact that's how the first Lisp compiler was written.  The
interpretter was written first, the compiler was written in Lisp
and then used in the interpretter to compile itself.
-- 
Michael M Rubenstein

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

[Fergus Henderson]

Richard Heathfield <binary@eton.powernet.co.uk> writes:

>Markus Mottl wrote:
>> 
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,
>
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though.

Sure you can, you just need to write in a subset of the language
that happens to *also* be valid in some other language.

For example, for the first implementation of the Mercury compiler,
we wrote it in the intersection of Mercury and Prolog;
we used a Prolog compiler to compile the first version, but the source
was also valid Mercury code, so we were then able to bootstrap
using the same sources.

I wouldn't be surprised if Bjarne Stroustrup did a similar thing with Cfront,
writing it in the intersection of C and "C with classes".

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

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

[Chris Kuan]

fjh@cs.mu.oz.au (Fergus Henderson) wrote in comp.lang.c++:

>I wouldn't be surprised if Bjarne Stroustrup did a similar thing with
>Cfront, writing it in the intersection of C and "C with classes".

D&E 3.3 ("Cfront") states that "Cfront was originally written in C with Classes 
and soon transcribed into C84 so that the very first working C++ compiler was 
entirely done in C++".

-- 
Chris Kuan, CSC (Australia)
Concatenate for email: mr gazpacho @ hotmail . com

"Law is a repository for the aimlessly clever" - Tim Freedman

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

[Chris Kuan]

look@sig.please.because.this.is.invalid (Chris Kuan) wrote in
comp.lang.c: 

Er, I sent follow-ups to the wrong groups. Ugh.

-- 
Chris Kuan, CSC (Australia)
Concatenate for email: mr gazpacho @ hotmail . com

"Law is a repository for the aimlessly clever" - Tim Freedman

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

[Zoltan Somogyi]

Richard Heathfield <binary@eton.powernet.co.uk> writes:
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though. (Or at least, if you can, you are probably related to
>Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
>too.)

The Melbourne Mercury compiler is the first (and so far only) implementation
of the Mercury language, and it is written in Mercury. During the bootstrapping
period, we confined ourselves to the intersection of Mercury and Prolog, and
used a Prolog implementation to execute the compiler. None of us are related
to any of those people as far as I know. :-) This is an exception from your
rule, because the first "implementation" of Mercury was in Mercury as well as
in Prolog. What counts is not whether the first implementation is in its own
language, but whether it is (also) in a language that already has an
implementation.

The other exception to your rule is that one can write the first compiler for
language X in language X itself, and hand-tranlate that to machine code.
People don't usually call hand-translation an "implementation", and thus
the compiler remains the first "implementation" of language X. Most people
wouldn't call this approach feasible, but theoretically its feasibility
is limited only by the hand-translator's patience ... :-)

Zoltan Somogyi <zs@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science and Software Engineering, Univ. of Melbourne

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

[Wes Groleau]

> > Any language that attempts to be called serious bootstraps
> > itself. Needless to say that the first compiler of a new language wasn't
> > written in the language itself,
> 
> Just a small nit - there's nothing to stop you writing the first
> compiler of a new language using an interpreter for that language. I

I believe the first version of GNAT was actually written in Ada
and compiled with an Ada 83 compiler.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Bruce G. Stewart]

Markus Mottl wrote:

> Any language that attempts to be called serious bootstraps
> itself. Needless to say that the first compiler of a new language wasn't
> written in the language itself, but the same holds true for C/C++...

Perhaps this is true of any language that aspires to be suitable for
writing compilers. It would be silly to restrict onself to writing, say,
an SQL statement compiler as an SQL statement.

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

[Kaz Kylheku]

In article <3B68C447.4F6C2F6B@worldnet.att.net>, Bruce G. Stewart wrote:
>Markus Mottl wrote:
>
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself, but the same holds true for C/C++...
>
>Perhaps this is true of any language that aspires to be suitable for
>writing compilers. It would be silly to restrict onself to writing, say,
>an SQL statement compiler as an SQL statement.

Note that everything that SQL does could be expressed in a serious
language that bootstraps itself.  E.g. a Lisp form could represent a
structured query.  So the existence of a dedicated language just for
database queries is superfluous.

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

[David Starner]

Kaz Kylheku <kaz@ashi.footprints.net> wrote in message
news:WG3a7.3350$B37.128229@news1.rdc1.bc.home.com...
> In article <3B68C447.4F6C2F6B@worldnet.att.net>, Bruce G. Stewart wrote:
> >Markus Mottl wrote:
> >
> >> Any language that attempts to be called serious bootstraps
> >> itself. Needless to say that the first compiler of a new language
wasn't
> >> written in the language itself, but the same holds true for C/C++...
> >
> >Perhaps this is true of any language that aspires to be suitable for
> >writing compilers. It would be silly to restrict onself to writing, say,
> >an SQL statement compiler as an SQL statement.
>
> Note that everything that SQL does could be expressed in a serious
> language that bootstraps itself.  E.g. a Lisp form could represent a
> structured query.  So the existence of a dedicated language just for
> database queries is superfluous.

Sure, you can hack a database query language unto the side of any "serious"
language, and implement it. You've then spent much time implementing a
"serious" language and a little time writing a database query language,
which is all you really needed. Oh, and now you need to filter all queries
coming into your database, because they can include arbitrary code.

Yes, the existance of a dedicated language just for database queries is
superfluous. So is the existance of all programming languages but one - you
can do everything in BASIC, or JOVIAL, or BLISS. Woo hoo.

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

[Kaz Kylheku]

In article <9kakda$f11$1@news-central.tiac.net>, David Starner wrote:
>Kaz Kylheku <kaz@ashi.footprints.net> wrote in message
>news:WG3a7.3350$B37.128229@news1.rdc1.bc.home.com...
>> In article <3B68C447.4F6C2F6B@worldnet.att.net>, Bruce G. Stewart wrote:
>> >Markus Mottl wrote:
>> >
>> >> Any language that attempts to be called serious bootstraps
>> >> itself. Needless to say that the first compiler of a new language
>wasn't
>> >> written in the language itself, but the same holds true for C/C++...
>> >
>> >Perhaps this is true of any language that aspires to be suitable for
>> >writing compilers. It would be silly to restrict onself to writing, say,
>> >an SQL statement compiler as an SQL statement.
>>
>> Note that everything that SQL does could be expressed in a serious
>> language that bootstraps itself.  E.g. a Lisp form could represent a
>> structured query.  So the existence of a dedicated language just for
>> database queries is superfluous.
>
>Sure, you can hack a database query language unto the side of any "serious"
>language, and implement it.

If that language is Lisp or something like it, then you only have to
write code in that language; you don't have to hack the language. That's
because the parser is available to you; you can call on it to parse and
give you the resulting structure.

>You've then spent much time implementing a
>"serious" language and a little time writing a database query language,
>which is all you really needed.

You are assuming that everything is done from scratch: first the
implementation language and then the query language. If that is the case,
it's a lot of work no matter what.

But suppose the implementation language is already available, and your
job is only to write a database language.  Then depending on what kind of
implementation language you have, the difficulty of your task will vary.

>Oh, and now you need to filter all queries
>coming into your database, because they can include arbitrary code.

In Lisp, there is already a parser built in that will give you a tree. 
That tree could be code or data; the representation is uniform.  You can
process that tree. That's a labor saving right there; not having to write
a parser, just worry about the structure that pops out.  That structure
could support an arbitrarily complex syntax for representing queries.

Think about all the time wasted implementing parsers for all these silly
data formats like SQL and XML, when there is a programming language that
can uniformly handle structured data in its own syntax: query languages,
markup languages, you name it.

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

[Markus Mottl]

In comp.lang.functional Bruce G. Stewart <bruce.g.stewart@worldnet.att.net> wrote:
> Perhaps this is true of any language that aspires to be suitable for
> writing compilers. It would be silly to restrict onself to writing,
> say, an SQL statement compiler as an SQL statement.

I think the context of the thread makes it clear that we are considering
"universal" programming languages only, not in the sense of computational
power but practical applicability.

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.

[Preben Randhol]

On 01 Aug 2001 13:36:54 -0700, Micah Cowan wrote:
> 
> If you confine yourself to safe string use, you will have no
> difficulties.  Power always comes at the risk of its abuse. So?

Again with the if. Why should one waste time on checking the code for
buffer overflow errors (which are so numerous in both M$ and Linux
software that some alarm bells ought to go off even for C/C++ fans) when
the language does it for you. Especially when you think that most
software are developed by several people, over time. You don't have
_one_ person that knows all the code. The code usually evolves. 

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.

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

[Leif Roar Moldskred]

[Followup set to c.l.a only]

In comp.lang.ada Beelsebob <tatd100@cs.york.ac.uk> wrote:

[Snip]

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

That's right, sir. Unlike with other computer languages, when you
shoot yourself in the foot with Ada, you don't just get a measly
little pin-prick of a buffer-overflow. No sir, when you shoot yourself
in the foot with Ada - you blast it clean off at the knee!

(As an aside, I believe that the program was actually correct
(i.e. behaved according to specifications), but had been misapplied.)


-- 
Leif Roar Moldskred
"Ada - fewer, more _interesting_ bugs."

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

[Charles Krug]

I think our Original Troll underestimates the ingenuity of programmers.

I'm absolutly certain of my ability to write code to crash an Arian rocket in
ANY language . . . <VBG>

Where's our resident Eiffle advocate?  Why hasn't he weighed in yet?

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

[Marin David Condic]

That's a little unfair. I don't think anyone was ever claiming that usage of
Ada or any other language was ever going to stop you from producing code
that had errors in it. The original idea was that languages exist (of which
Ada is one) that perform compile time and runtime checks that reduce or
eliminate whole classes of errors and that this is a good and desirable
thing. Evidence exists to indicate that stronger, more robust, more
reliable, more secure systems tend to get built if compilers check for
common, everyday programming errors and eliminate them. Nobody ever said you
can't build reliable software in languages that *don't* perform these sorts
of checks, but it isn't a stretch to claim that the level of effort is going
to be higher and the probability of success lower. Hence, the case is being
made that perhaps developers should consider safety and security concerns
when selecting a language for implementation. That hardly seems like some
wild-eyed claim that using Ada (or whatever language du jour you like) is
going to prevent programmers from building things that fail.

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/


"Beelsebob" <tatd100@cs.york.ac.uk> wrote in message
news:65bd5935.0108020356.16c61e15@posting.google.com...
> [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 service attack.

[Mike Silva]

tatd100@cs.york.ac.uk (Beelsebob) wrote in message news:<65bd5935.0108020356.16c61e15@posting.google.com>...
> [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.....

So if I can distill your message, a program that performs exactly to
spec is supposed to somehow reflect badly on the language that the
program is written in?

That old stinkbomb reflects more on the people who toss it than on
Ada.

Mike

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

[Robert Dewar]

"Mike Smith" <smithmc@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpmb575l80@corp.supernews.com>...
> "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?


Sounds like Mike is not familiar with Ada. Of course Ada does not
guarantee freedom from bugs, but for many reasons it does tend to
eliminate obvious goofs like buffer overruns, which are indeed
"endemic" to C and C++ in that these languages do not provide any
help for avoiding such bugs, and as we know these buffer overrun
bugs have time and time again proved weak spots in code written
in C/C++.

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

[Ted Dennison]

In article <5ee5b646.0108010949.5abab7fe@posting.google.com>, Robert Dewar
says...
>
>"Mike Smith" <smithmc@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpmb575l80@corp.supernews.com>...
>> 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?
>
>
>Sounds like Mike is not familiar with Ada. Of course Ada does not
>guarantee freedom from bugs, but for many reasons it does tend to
>eliminate obvious goofs like buffer overruns, which are indeed
>"endemic" to C and C++ in that these languages do not provide any
>help for avoiding such bugs, and as we know these buffer overrun
>bugs have time and time again proved weak spots in code written
>in C/C++.

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.
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. You'd have to disable array range
checks (and possibly constraint checks too) with either a pragma or a compiler
flag when the sources are built. It can be done when you need to (sometimes the
extra speed is important), but most folks use the default, which is immune.

If you don't think this is a big problem, check out this cracker website, which
is dedicated to teaching young script kiddies how to exploit Windows Buffer
Overflows: http://www.cultdeadcow.com/cDc_files/cDc-351/
My own company blocks it, but I understand it is titled: "The Tao of Windows
Buffer Overflow". :-)

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

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

[Marin David Condic]

Well, that's rather assuming that there will be some constant level of bugs
in all software regardless of language of implementation. If on average the
number of bugs in a large body of applications written in Assembler, C, C++,
Ada and Zerble were constant in both quantity and quality, (just taking
different forms) then there wouldn't be much point in injecting any sort of
language checks to prevent bugs. This seems kind of obviously silly - checks
put into languages to find and prevent bugs do have some impact on the
overall number of bugs. (Granted, we're talking about statistical averages -
maybe the Ada code I write is really crappy in comparison to the C code you
write and so for a similar effort on our parts, you may have fewer bugs. But
that's hardly the point.)

FWIW, I did a study at one time with metrics collected over a ten year span
of time comparing Ada development versus development in a variety of other
languages. There was a reduction in errors by a factor of four. Same
programmers, different projects. There is quite a bit of evidence to
indicate that errors can be reduced by language checks. That has practical
implications in terms of profits and losses.

Check out:

http://www2.dynamite.com.au/aebrain/ADACASE.HTM
http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp
http://www.rational.com/products/whitepapers/337.jsp

There you will find additional evidence that language choice *does* make a
difference in terms of productivity and defects.

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/


"Chris Torek" <torek@BSDI.COM> wrote in message
news:9k9if8$rn3$1@elf.eng.bsdi.com...
>
> 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." :-)
>

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

[Chris Torek]

In article <9k9nci$1cq$1@nh.pace.co.uk>
Marin David Condic <marin.condic.auntie.spam@pacemicro.com> writes:
>Well, that's rather assuming that there will be some constant level of bugs
>in all software regardless of language of implementation.

No, not at all.  I agree that there are (more or less) objective
measures that show that the defect rate in some languages (e.g.,
Ada) is far lower than the defect rate in other languages (C,
assembler, etc).  I will even agree with one who argues that it
would be harder to break into a system with 100 defects than one
with 1000.  But as far as actual breakins go:

>There you will find additional evidence that language choice *does*
>make a difference in terms of productivity and defects.

Until you get the number of defects close to zero -- I am not sure
"how close" is required; obviously zero suffices, given an appropriate
definition of defects; but I think zero is also unachievable unless
given an inappropriate definition :-) -- there will still be
"exploitable bugs" in systems.  My argument is that, if we somehow
achieved this more perfect world, the crackers would simply change
their tactics: instead of using easily-cracked buffer overflow
bugs, they would use more-difficult (but available today) tricks
like TCP session record and replay.

The "real world" analogy of locks is useful here.  Locks can keep
"mostly-honest" people honest, and the better the locks, the greater
this effect becomes.  It is certainly foolish to say: "well, this
cheap lock does not stop some thieves, therefore we should eliminate
all locks" -- but it is equally foolish to say "aha, this more-expensive
lock stopped that particular thief, therefore we should all just
use this lock and decree perfection".

In other words, I do not dispute that code written in Ada tends to
be better; I just think it is a mistake to go from there to "if
only Microsoft wrote in Ada, there would be no more Code-Reds."
-- 
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.

[Larry Kilgallen]

In article <9k9s85$s0o$1@elf.eng.bsdi.com>, Chris Torek <torek@BSDI.COM> writes:

> Until you get the number of defects close to zero -- I am not sure
> "how close" is required; obviously zero suffices, given an appropriate
> definition of defects; but I think zero is also unachievable unless
> given an inappropriate definition :-) -- there will still be
> "exploitable bugs" in systems.  My argument is that, if we somehow
> achieved this more perfect world, the crackers would simply change
> their tactics: instead of using easily-cracked buffer overflow
> bugs, they would use more-difficult (but available today) tricks
> like TCP session record and replay.

If those other tactics are more difficult, it means productivity
(in the cracking business) is lower using those tactics. Otherwise
those tactics would be in wider use today.  Perhaps they are even
less easily spread to Script Kiddies.

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

[Florian Weimer]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> If those other tactics are more difficult, it means productivity
> (in the cracking business) is lower using those tactics. Otherwise
> those tactics would be in wider use today.  Perhaps they are even
> less easily spread to Script Kiddies.

For what it's worth, there are more or less script-kiddy compatible
tools for non-transparent proxying of SSH and SSL connections.

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

[Marin David Condic]

Well I would certainly agree (to a point) with your lock analogy. No
language (or lock) is going to entirely prevent exploitable holes in systems
because holes result from logic errors as well as simple programming errors.
Hence, it is correct to conclude that if only Microsoft used Ada there would
still be the possibility of security breeches. But I'd still argue that
usage of a given language that includes stronger checks for errors
ultimately results in a stronger lock. The stronger the lock, the less
likelihood someone is going to break in - or at least you've reduced the
number of thieves you've got to worry about. The fact that somewhere there
exists one thief who can break any lock doesn't mean I should quit locking
my front door.

A more important question to toss out would be "What is the cost incurred
when someone *does* find a hole to exploit and *does* break in?" If you are
building an OS that is going to be used by web servers, that cost can be
pretty high. If the cost is high, one ought to consider investing in the
stronger lock rather than the dime-store-cheapie that can be got around with
a bobby pin. That's where Microsoft might have a big advantage by developing
an OS using Ada - it doesn't cover all the possible holes, but it sure is
going to cover some non-trivial number of them and that might save them and
their customers a lot of money by preventing some number of attacks. Call it
"Insurance".

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/


"Chris Torek" <torek@BSDI.COM> wrote in message
news:9k9s85$s0o$1@elf.eng.bsdi.com...
> In article <9k9nci$1cq$1@nh.pace.co.uk>
>
> No, not at all.  I agree that there are (more or less) objective
> measures that show that the defect rate in some languages (e.g.,
> Ada) is far lower than the defect rate in other languages (C,
> assembler, etc).  I will even agree with one who argues that it
> would be harder to break into a system with 100 defects than one
> with 1000.  But as far as actual breakins go:
>
> >There you will find additional evidence that language choice *does*
> >make a difference in terms of productivity and defects.
>
> Until you get the number of defects close to zero -- I am not sure
> "how close" is required; obviously zero suffices, given an appropriate
> definition of defects; but I think zero is also unachievable unless
> given an inappropriate definition :-) -- there will still be
> "exploitable bugs" in systems.  My argument is that, if we somehow
> achieved this more perfect world, the crackers would simply change
> their tactics: instead of using easily-cracked buffer overflow
> bugs, they would use more-difficult (but available today) tricks
> like TCP session record and replay.
>
> The "real world" analogy of locks is useful here.  Locks can keep
> "mostly-honest" people honest, and the better the locks, the greater
> this effect becomes.  It is certainly foolish to say: "well, this
> cheap lock does not stop some thieves, therefore we should eliminate
> all locks" -- but it is equally foolish to say "aha, this more-expensive
> lock stopped that particular thief, therefore we should all just
> use this lock and decree perfection".
>
> In other words, I do not dispute that code written in Ada tends to
> be better; I just think it is a mistake to go from there to "if
> only Microsoft wrote in Ada, there would be no more Code-Reds."

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

[CBFalconer]

Marin David Condic wrote:
> 
... snip ...
> 
> A more important question to toss out would be "What is the cost incurred
> when someone *does* find a hole to exploit and *does* break in?" If you are
> building an OS that is going to be used by web servers, that cost can be
> pretty high. If the cost is high, one ought to consider investing in the
> stronger lock rather than the dime-store-cheapie that can be got around with
> a bobby pin. That's where Microsoft might have a big advantage by developing
> an OS using Ada - it doesn't cover all the possible holes, but it sure is
> going to cover some non-trivial number of them and that might save them and
> their customers a lot of money by preventing some number of attacks. Call it
> "Insurance".

** PLEASE do not top-post.  I am tired of fixing quotations or
losing continuity.

A suitable carrot would be responsibility for software
performance.  If firms refused to buy systems or applications
without suitable performance warranties, and sued for failure to
meet those warranties, software would rapidly improve.  Bottom
lines might not (improve) for some shakeout time.

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

[Larry Kilgallen]

In article <9k9nci$1cq$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> Well, that's rather assuming that there will be some constant level of bugs
> in all software regardless of language of implementation. If on average the
> number of bugs in a large body of applications written in Assembler, C, C++,
> Ada and Zerble were constant in both quantity and quality, (just taking
> different forms) then there wouldn't be much point in injecting any sort of
> language checks to prevent bugs. This seems kind of obviously silly - checks
> put into languages to find and prevent bugs do have some impact on the
> overall number of bugs. (Granted, we're talking about statistical averages -
> maybe the Ada code I write is really crappy in comparison to the C code you
> write and so for a similar effort on our parts, you may have fewer bugs. But
> that's hardly the point.)

A minor point is that I cannot figure out whether Marin or Chris is the
one more likely to write bug-free code.

A major point is that neither can Microsoft.

At a 50,000 foot level, it is better to equip the troops with tools that
have safety guards on them.  They may remove the guards from time to time,
but that is better than for a giant corporation to pretend it is capable
of only hiring people who are so skilled that they would never need a
safety guard.

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

[Richard Bos]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:

> A minor point is that I cannot figure out whether Marin or Chris is the
> one more likely to write bug-free code.

I have no idea how good Marin is, but I'd trust Chris's code over, well,
almost anyone's. Certainly including my own. The reason? I've seen some
of Chris's code in the past, and it is generally as bug-free as any code
I've seen in any language.

Richard

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

[Larry Kilgallen]

In article <3b6903f5.1111682555@news.worldonline.nl>, info@hoekstra-uitgeverij.nl (Richard Bos) writes:
> Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> 
>> A minor point is that I cannot figure out whether Marin or Chris is the
>> one more likely to write bug-free code.
> 
> I have no idea how good Marin is, but I'd trust Chris's code over, well,
> almost anyone's. Certainly including my own. The reason? I've seen some
> of Chris's code in the past, and it is generally as bug-free as any code
> I've seen in any language.

Try to extrapolate, then, to the situation where you don't know the
individual.  Very few people are able to restrict their use of computer
software to that where they have personal knowledge of the individual.

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

[Chris Torek]

In article <3b6903f5.1111682555@news.worldonline.nl>
Richard Bos <info@hoekstra-uitgeverij.nl> writes:
>I have no idea how good Marin is, but I'd trust Chris's code over, well,
>almost anyone's. Certainly including my own. The reason? I've seen some
>of Chris's code in the past, and it is generally as bug-free as any code
>I've seen in any language.

No matter how good it may be, it does still have bugs.  More
importantly, it has "defects", which are not necessarily the same
thing.  As a nice way of describing the difference, imagine a
program that calculates pi to any given number of decimal places,
and does so correctly every time.  "Bug-free", perhaps -- but if
the task is to calculate e, not pi, then the program has an obvious
"defect". :-)

Others may use the terminology differently (e.g., interchangeably),
but I like this distinction -- it is like the one between tactics
and strategy.

An advantage to Ada (and I will say that I rather like the newer
Ada, even without actually ever having used it for anything) is
that you can tend to concentrate on the "defects" rather than the
"bugs", because the strictness of the language causes the compiler
to catch more of the latter.  It always seemed to me that functional
programming languages were even better in this respect; their usual
drawback is in terms of performance.  (Early Ada compilers like
the Verdix one the U of MD tested built huge, slow programs, but
I understand this is no longer much of a problem.  One of these
days I must get around to playing with Gnat...)
-- 
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.

[Dan Cross]

In article <9kci3p$ri$1@elf.eng.bsdi.com>, Chris Torek  <torek@BSDI.COM> wrote:
>Others may use the terminology differently (e.g., interchangeably),
>but I like this distinction -- it is like the one between tactics
>and strategy.

IMHO, the use of the term ``bug'' to describe an error in a piece of
software is a cop-out on the part of software engineers and
programmers.  The term ``bug'' implies that it's beyond the control of
the programmer, when in reality, software has no bugs which aren't
placed there by the person who writes it (sometimes directly, sometimes
indirectly).

Was it Hoare who said something along the lines of, ``it's a lot easier
for a programmer to say, `the software still has a few bugs' than to
say, `the software is full of defects I put there.' ''

My take on your distinctin between `bug' and `defect' is that software
systems have to be evaluated in their totality, and that that totality
contains multiple levels.  Ie, requirements, design, implementation,
etc.  Defects can occur at any level, but they're still defects.  The
union of set of all requirements defects, design defects, and
implementation defects (and others, if appropriate) forms the set of
all defects of the system.

To bring this back around to security for a moment....  I've long
maintained that security is simply a proper subset of correctness at
all levels; be it implementation, design, requirements, etc.  Someone
has proposed a definition that a correct program does what it's
supposed to for all inputs, while a secure program does what it's
supposed to and nothing else for all inputs.  I think this is obtuse,
however, since under what conditions does a correct program NOT do
`nothing else'?

Anyway, if we say for a moment that a correct program (and remember,
this means ``correct at all levels'') is also a secure one, then using
tools which reduce instances of implementation defects is a decent way
to improve the security of software by cutting down on a whole class of
potentially security compromising defects.

Again, it comes back to choosing the appropriate tool for the job.
Those who blindly pick C for everything are making a huge mistake, as
are those who pick any other one language for all occasions.

	- Dan C.

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

[Kaz Kylheku]

In article <9kdeuv$dfh@augusta.math.psu.edu>, Dan Cross wrote:
>In article <9kci3p$ri$1@elf.eng.bsdi.com>, Chris Torek  <torek@BSDI.COM> wrote:
>>Others may use the terminology differently (e.g., interchangeably),
>>but I like this distinction -- it is like the one between tactics
>>and strategy.
>
>IMHO, the use of the term ``bug'' to describe an error in a piece of
>software is a cop-out on the part of software engineers and
>programmers. 

I sometimes like to use plain old ``mistake''. Even the word defect still
has a bit of a blame-shifting flavor, defects being things that just
``creep in'' from the environment. A factory can manufacture gadgets,
such that 1.48 out of every 1000 will have a defect, on average.
Nobody's fault, just a statistic! A defect rate that is accepted as
an artifact of the process.

>The term ``bug'' implies that it's beyond the control of
>the programmer, when in reality, software has no bugs which aren't
>placed there by the person who writes it (sometimes directly, sometimes
>indirectly).
>
>Was it Hoare who said something along the lines of, ``it's a lot easier
>for a programmer to say, `the software still has a few bugs' than to
>say, `the software is full of defects I put there.' ''

See? It seems necessary to add the qualifying words ``I put there'',
when you use ``defect''. As opposed to some defect that you didn't put
there, but which occured for some magic statistical reasons. ;)

But if you say ``the software is full of mistakes'', no further
qualification is needed. It's obvious who wrote it, and therefore
who made the mistakes.

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

[Dan Cross]

In article <mmra7.6956$B37.222069@news1.rdc1.bc.home.com>,
Kaz Kylheku <kaz@ashi.footprints.net> wrote:
>But if you say ``the software is full of mistakes'', no further
>qualification is needed. It's obvious who wrote it, and therefore
>who made the mistakes.

Hmm, I hear what you're saying; the only problem I have with `mistake'
is that it has a less severe connotation (``oh dang; I made a mistake
and ordered a coke instead of ginger ale...'', ``I made a mistake and
burned the muffins...'').  Maybe ``error'' is a better word.  ``The
software is full of errors.''

	- Dan C.

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

[Kaz Kylheku]

In article <9kecu6$f8i@augusta.math.psu.edu>, Dan Cross wrote:
>In article <mmra7.6956$B37.222069@news1.rdc1.bc.home.com>,
>Kaz Kylheku <kaz@ashi.footprints.net> wrote:
>>But if you say ``the software is full of mistakes'', no further
>>qualification is needed. It's obvious who wrote it, and therefore
>>who made the mistakes.
>
>Hmm, I hear what you're saying; the only problem I have with `mistake'
>is that it has a less severe connotation (``oh dang; I made a mistake
>and ordered a coke instead of ginger ale...'', ``I made a mistake and
>burned the muffins...'').  Maybe ``error'' is a better word.  ``The
>software is full of errors.''

I hear you. But again, ``error'' has a weakened meaning in the context
of computing, because it's sometimes used to mean ``an environmental
condition that software has to deal with'' like running out of memory,
bad sector on a disk, unreachable server, etc.

I don't know whether there is a word for ``mistake'' which also has
conntations of severity, so that it's inapplicable to situations like
ordering the wrong soft drink.  I checked an online thesaurus, and
it came up with nothing. ;)

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

[Ben Pfaff]

kaz@ashi.footprints.net (Kaz Kylheku) writes:

> I don't know whether there is a word for ``mistake'' which also has
> conntations of severity, so that it's inapplicable to situations like
> ordering the wrong soft drink.  I checked an online thesaurus, and
> it came up with nothing. ;)

"Blunder"?
-- 
"I should killfile you where you stand, worthless human." --Kaz

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

[Marc A. Criley]

Kaz Kylheku wrote:
> 
> In article <9kecu6$f8i@augusta.math.psu.edu>, Dan Cross wrote:
> >In article <mmra7.6956$B37.222069@news1.rdc1.bc.home.com>,
> >Kaz Kylheku <kaz@ashi.footprints.net> wrote:
> >>But if you say ``the software is full of mistakes'', no further
> >>qualification is needed. It's obvious who wrote it, and therefore
> >>who made the mistakes.
> >
> >Hmm, I hear what you're saying; the only problem I have with `mistake'
> >is that it has a less severe connotation (``oh dang; I made a mistake
> >and ordered a coke instead of ginger ale...'', ``I made a mistake and
> >burned the muffins...'').  Maybe ``error'' is a better word.  ``The
> >software is full of errors.''
> 
> I hear you. But again, ``error'' has a weakened meaning in the context
> of computing, because it's sometimes used to mean ``an environmental
> condition that software has to deal with'' like running out of memory,
> bad sector on a disk, unreachable server, etc.
> 
> I don't know whether there is a word for ``mistake'' which also has
> conntations of severity, so that it's inapplicable to situations like
> ordering the wrong soft drink.  I checked an online thesaurus, and
> it came up with nothing. ;)

Defect.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

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

[AG]

"Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
news:vABa7.11263$B37.246587@news1.rdc1.bc.home.com...
> In article <9kecu6$f8i@augusta.math.psu.edu>, Dan Cross wrote:
> >In article <mmra7.6956$B37.222069@news1.rdc1.bc.home.com>,
> >Kaz Kylheku <kaz@ashi.footprints.net> wrote:

> I don't know whether there is a word for ``mistake'' which also has
> conntations of severity, so that it's inapplicable to situations like
> ordering the wrong soft drink.  I checked an online thesaurus, and
> it came up with nothing. ;)

Crash? BSoD?

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

[Stefan Skoglund]

Kaz Kylheku wrote:
> I hear you. But again, ``error'' has a weakened meaning in the context
> of computing, because it's sometimes used to mean ``an environmental
> condition that software has to deal with'' like running out of memory,
> bad sector on a disk, unreachable server, etc.

I learned while in school to differ between weakness, error and failure.

Weakness is some point somewhere in the program which can cause problems
error is when the weakness rears its head but things still works because
of some sideeffect in the same/or some other part.

Failure is when nothing helps.

An example:
one of the attitude sensor in JAS gripen has tripple redundancy.
Why because the mtbf for this sensor is such that it will cause at least
two complete failures (ie unintentional contact with ground) over the
lifeline of this system. The failuremode of this sensor is easily
detectable
and so the system will log the error and change over to the next one.

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

[Ted Dennison]

In article <9kecu6$f8i@augusta.math.psu.edu>, Dan Cross says...
>
>In article <mmra7.6956$B37.222069@news1.rdc1.bc.home.com>,
>Kaz Kylheku <kaz@ashi.footprints.net> wrote:
>>But if you say ``the software is full of mistakes'', no further
>>qualification is needed. It's obvious who wrote it, and therefore
>>who made the mistakes.
>
>Hmm, I hear what you're saying; the only problem I have with `mistake'
>is that it has a less severe connotation (``oh dang; I made a mistake
>and ordered a coke instead of ginger ale...'', ``I made a mistake and
>burned the muffins...'').  Maybe ``error'' is a better word.  ``The
>software is full of errors.''

Its a silly arguement anyway. If everyone started saying "frobozz" whenever they
now say "bug", "frobozz" will just eventually come to mean the same thing. You
can't run away from the meaning people give a concept by meerly changing the
sounds you make with your mouth. 

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

[Dan Cross]

In article <9TBa7.16564$ar1.61061@www.newsranger.com>,
Ted Dennison <dennison@telepath.com> wrote:
>Its a silly arguement anyway. If everyone started saying "frobozz" whenever
>they now say "bug", "frobozz" will just eventually come to mean the same
>thing. You can't run away from the meaning people give a concept by meerly
>changing the sounds you make with your mouth. 

Yes, but if you chose a word that has a pre-existing and more severe
meaning, you achieve the desired effect.  The point isn't to create a
new term, it's to reuse an existing more appropriate term.

However, before re-using any terms, maybe we'd better make sure they
aren't going to blow up any rockets.  :-)

	- Dan C.

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

[Ted Dennison]

In article <9kestr$gm0@augusta.math.psu.edu>, Dan Cross says...
>
>In article <9TBa7.16564$ar1.61061@www.newsranger.com>,
>Ted Dennison <dennison@telepath.com> wrote:
>>Its a silly arguement anyway. If everyone started saying "frobozz" whenever
>>they now say "bug", "frobozz" will just eventually come to mean the same
>>thing. You can't run away from the meaning people give a concept by meerly
>>changing the sounds you make with your mouth. 
>
>Yes, but if you chose a word that has a pre-existing and more severe
>meaning, you achieve the desired effect.  The point isn't to create a
>new term, it's to reuse an existing more appropriate term.

No, it will just slowly take on the original meaning in that context, as people
come to realise what it is you are talking about. How many times has the
military changed their term for "Shell-Shocked"? Is it 3 or 4 now? The current
trend seems to be to use the acronym "PTSD". I think each time they tried to
combine milder and more inane words into the term, but in the end the meaning
kept catching up with them. So they'd have to change again. They still haven't
cottoned on to the fact that they are fighting a loosing battle with the human
mind.

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

[Tore Lund]

Ted Dennison wrote:
> 
> Its a silly arguement anyway. If everyone started saying "frobozz" whenever they
> now say "bug", "frobozz" will just eventually come to mean the same thing. You
> can't run away from the meaning people give a concept by meerly changing the
> sounds you make with your mouth.

Where I used to work, a minor bug was called an "adjustment".  If it was
more deep-seated, we called it a "hardware problem".  Even worse, it was
an "occult phenomenon".

I bet they called it an "oversight" before that insect was found and the
term "bug" was invented.  That is the most direct and honest word for
it.  The effect of an oversight can be quite trivial, but it could also
trigger off World War III.  If we need a new word, I vote for
"oversight".
-- 
    Tore

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

[Keith Thompson]

Tore Lund <tl001@online.no> writes:
[...]
> I bet they called it an "oversight" before that insect was found and the
> term "bug" was invented.  That is the most direct and honest word for
> it.  The effect of an oversight can be quite trivial, but it could also
> trigger off World War III.  If we need a new word, I vote for
> "oversight".

Quibble: the term "bug" didn't originate in the discovery of an
insect, at least not the one you're probably thinking of.  The moth in
a relay of the Harvard Mark II was logged as "First actual case of bug
being found", indicating that the term already existed.

See <http://www.tuxedo.org/~esr/jargon/html/entry/bug.html>.

-- 
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: How Ada could have prevented the Red Code distributed denial of service attack.

[Warren W. Gay VE3WWG]

Keith Thompson wrote:
> Tore Lund <tl001@online.no> writes:
> [...]
> > I bet they called it an "oversight" before that insect was found and the
> > term "bug" was invented.  That is the most direct and honest word for
> > it.  The effect of an oversight can be quite trivial, but it could also
> > trigger off World War III.  If we need a new word, I vote for
> > "oversight".
> 
> Quibble: the term "bug" didn't originate in the discovery of an
> insect, at least not the one you're probably thinking of.  The moth in
> a relay of the Harvard Mark II was logged as "First actual case of bug
> being found", indicating that the term already existed.
> 
> See <http://www.tuxedo.org/~esr/jargon/html/entry/bug.html>.

Thomas Edison and his assistants also used to refer to "bugs",
though this was not in a "computing context".

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

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

[kers]

In article <3B6B1D86.153D54F1@online.no>,
	Tore Lund <tl001@online.no> writes:
> Ted Dennison wrote:
>> 
>> Its a silly arguement anyway. If everyone started saying "frobozz" whenever they
>> now say "bug", "frobozz" will just eventually come to mean the same thing. You
>> can't run away from the meaning people give a concept by meerly changing the
>> sounds you make with your mouth.
> 
> Where I used to work, a minor bug was called an "adjustment".  If it was
> more deep-seated, we called it a "hardware problem".  Even worse, it was
> an "occult phenomenon".

In a previous existance, minor bugs were called "buggettes". (Major bugs
were also called "buggettes", but but only to those that understood
English understatement.)

> I bet they called it an "oversight" before that insect was found and the
> term "bug" was invented.  That is the most direct and honest word for
> it.  The effect of an oversight can be quite trivial, but it could also
> trigger off World War III.  If we need a new word, I vote for
> "oversight".

"Oversight" has too many syllables.

-- 
Chris "'mistake is pushing the limit" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html

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 <9kci3p$ri$1@elf.eng.bsdi.com>, Chris Torek  <torek@BSDI.COM> wrote:
> >Others may use the terminology differently (e.g., interchangeably),
> >but I like this distinction -- it is like the one between tactics
> >and strategy.
> 
> IMHO, the use of the term ``bug'' to describe an error in a piece of
> software is a cop-out on the part of software engineers and
> programmers.  The term ``bug'' implies that it's beyond the control of
> the programmer,

Says who? When I write a bug, it's _my_ bug.

<sarcasm>
Of course, when you use a language that will prevent you from making
mistakes, any bugs in the software could not possibly be yours.
</sarcasm>

That's why I check and test my programs before using them for production
work. With "modern" programmers, that's becoming an ever rarer
procedure, alas.

Richard

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

[Dan Cross]

In article <3b6a4414.1193645865@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>Says who? When I write a bug, it's _my_ bug.

I see.  And have you ever worked on a project with more than one
programmer?

><sarcasm>
>Of course, when you use a language that will prevent you from making
>mistakes, any bugs in the software could not possibly be yours.
></sarcasm>

Who ever said there was a language that would prevent one from making a
mistake?  Certainly not I, nor anyone in this thread, AFAIK.  Perhaps
you'd care to post a reference to what you're refering to?

>That's why I check and test my programs before using them for production
>work. With "modern" programmers, that's becoming an ever rarer
>procedure, alas.

Indeed, today's programmer's attitude towards quality and quality
assurance represents a sad truly state of affairs.  Case in point,
programmers who feel that their work is done in a bubble, and refuse to
use tools which are likely to reduce [*] instances of error injection.

	- Dan C.

[*]  Note that I said `reduce'.  Not `eliminate', but `reduce'.

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 <3b6a4414.1193645865@news.worldonline.nl>,
> Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> >Says who? When I write a bug, it's _my_ bug.
> 
> I see.  And have you ever worked on a project with more than one
> programmer?

Sure. And when I write a bug, it's still my bug. When one of us writes a
bug but I don't know who did it yet, it's our bug. It's called
"responsibility". And it's the programmer's responsibility, _not_ the
tools'.

> ><sarcasm>
> ></sarcasm>
> 
> Who ever said there was a language that would prevent one from making a
> mistake?

You patently do not understand the meaning of the word "sarcasm". You
must be a USAlien.

> >That's why I check and test my programs before using them for production
> >work. With "modern" programmers, that's becoming an ever rarer
> >procedure, alas.
> 
> Indeed, today's programmer's attitude towards quality and quality
> assurance represents a sad truly state of affairs.  Case in point,
> programmers who feel that their work is done in a bubble, and refuse to
> use tools which are likely to reduce [*] instances of error injection.

Such as? Let me remind you that array bounds checking only allows you to
spot array bounds infringements _after_ they have happened. Only a
thorough design can help prevent bugs to occur in the first place.

Richard

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

[Dan Cross]

In article <3b6e981c.1477345425@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>> I see.  And have you ever worked on a project with more than one
>> programmer?
>
>Sure. And when I write a bug, it's still my bug. When one of us writes a
>bug but I don't know who did it yet, it's our bug. It's called
>"responsibility". And it's the programmer's responsibility, _not_ the
>tools'.

If the programmer is really taking responsibility for his or her
actions, why would he or she willingly choose to use a tool that s/he
was more likely to make a mistake with?  Wouldn't programmers with this
sense of responsibility be lining up to use tools that would enhance
the safety of their software?

...or is it that they're too macho to admit their fallability and instead
come up with lame excuses on the order of, ``I make sure to be aware of
what I'm doing when I program!''

Well, we all try to do the latter, but what seperates the good
programmers from the really great ones is that the latter recognize
their own limitations and react accordingly, including using tools that
are safer.

But no one ever said that, ``oh, the tool will take care of it.''  What
we did say was, ``the tool helps the programmer to take care of it.''
And that's the important distinction; tools can't solve problems for
us, but some tools are more effective than others at assisting us to
solve problems.

As has been stated before in this thread, none of us are 100% all the
time.  We make mistakes; we're human.  It's the wise programmer who
recognizes this and takes it into account by using tools he or she
knows will catch some of those mistakes.  She takes responsibility for
her actions and attempts to address her natural, humanistic
shortcomings by equiping herself with the best tools for the job.

>> Who ever said there was a language that would prevent one from making a
>> mistake?
>
>You patently do not understand the meaning of the word "sarcasm". You
>must be a USAlien.

You resport to ad hominem attacks when your logic breaks down.  You
must be an arrogant European.  :-)

>> Indeed, today's programmer's attitude towards quality and quality
>> assurance represents a sad truly state of affairs.  Case in point,
>> programmers who feel that their work is done in a bubble, and refuse to
>> use tools which are likely to reduce [*] instances of error injection.
>
>Such as? Let me remind you that array bounds checking only allows you to
>spot array bounds infringements _after_ they have happened. Only a
>thorough design can help prevent bugs to occur in the first place.

Such as, oh, I don't know, programming in Ada instead of C, making
their code legible enough to be reviewed by their peers, actually
thinking about what they're doing.  That sort of thing.

Of course, no one argues that good design (and before that,
requirements gathering and analysis) are requisite for reducing
defects. In particular, I've stated in this thread that it is
absolutely important.  But, it's not the only thing, and any tool that
helps us catch those other errors is a Good Thing.

btw- Array bounds checking isn't the only thing that Ada does to help
protect the programmer from his or herself.  I will note, however, that
it's a lot nicer to get an array bounds exception and handle it
accordingly than to simply have a program crash with a segmentation
violation or bus error; both common things in C.

	- Dan C.

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

[Scott Ingram]

Richard Bos wrote:

> 
> Such as? Let me remind you that array bounds checking only allows you to
> spot array bounds infringements _after_ they have happened. Only a
> thorough design can help prevent bugs to occur in the first place.
> 

Actually, Ada compilers check array bounds at compile time.  Many array
constructs can be built using Ada language features that impose no
runtime penalty, and using those features is part of the design process.

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

[Marin David Condic]

The "Any *competent* programmer..." argument never holds up when the number
of programmers needed to do the job gets much beyond "1" - and probably not
even then. Here's a simple fact of life: People are stupid from time to
time. Some more than others. Some more frequently than others. Some in a
continuous state of stupidity. When you have to hire 1000 programmers for
some job at hand, you can bet your life that the staff is not going to be
100% "A-Team" players. If you are counting on everyone being 100% at all
times in order to not produce stupid errors, then you're living in a fool's
paradise.

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/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:$Id63yuv4BjB@eisner.encompasserve.org...
> At a 50,000 foot level, it is better to equip the troops with tools that
> have safety guards on them.  They may remove the guards from time to time,
> but that is better than for a giant corporation to pretend it is capable
> of only hiring people who are so skilled that they would never need a
> safety guard.

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

[Mike Silva]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in message news:<9kbqea$obt$1@nh.pace.co.uk>...
> The "Any *competent* programmer..." argument never holds up when the number
> of programmers needed to do the job gets much beyond "1" - and probably not
> even then. Here's a simple fact of life: People are stupid from time to
> time. Some more than others. Some more frequently than others. Some in a
> continuous state of stupidity. When you have to hire 1000 programmers for
> some job at hand, you can bet your life that the staff is not going to be
> 100% "A-Team" players. If you are counting on everyone being 100% at all
> times in order to not produce stupid errors, then you're living in a fool's
> paradise.

Once I watched two drivers "disagree."  After a bit, one of the
drivers simply began responding "Because you're stupid!" to everything
the other driver said.  Whenever I read "any *competent*
programmer..." or the like I'm reminded of "Because you're stupid!" 
Yes, even the most competent person is stupid, to a greater or lesser
degree, from moment to moment.  As Nancy Leveson drolly stated in
"Safeware" (slight paraphrase): "Telling <people> not to make mistakes
in not productive."

I can think of no logical reason not to use tools that can catch
common human programming errors, whether at compile time or runtime
(and for those who complain about a few percent performance hit at
runtime, it's almost certainly not a real issue, but if it is (a) wait
a week and buy faster hardware, or (b) turn off the most time-critical
checks).  It really is time to get past the "real programmers vs.
sissies" attitude I see in so many of these discussions.

Mike 

> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> news:$Id63yuv4BjB@eisner.encompasserve.org...
> > At a 50,000 foot level, it is better to equip the troops with tools that
> > have safety guards on them.  They may remove the guards from time to time,
> > but that is better than for a giant corporation to pretend it is capable
> > of only hiring people who are so skilled that they would never need a
> > safety guard.

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

[Florian Weimer]

Chris Torek <torek@BSDI.COM> writes:

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

The problem with buffer overflow bugs is that they are very hard to
discover if the first audit occurs after the software has been out
for years (and changed many times, by different persons).  If you're
coding from scratch, you can try to follow a rule that it must be
obvious that there aren't any such problems, but that's not an option
with existing code, and not many people seem to follow this route
anyway.

Other C-eminent problems (for example, bugs related to improper use
of format strings) can be checked for almost automatically, so they
aren't such a big problem.

Other kinds of defects still have the potential of being very severe
(for example, look at the recent problem with SSH 3.0.0).  My
subjective impression is that remote code injection attacks usually
have far more potential for harm than these other defects, but this
observation might just reflect the fact that in the latter cases, the
impact of the vulnerability varies much more from defect to defect.

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.

[David Gillon]

Goran Larsson wrote:

> The report clearly shows that you can have problematic software in
> any language. 

Perhaps more appropriately, choice of software implementation language
cannot alleviate design failures at the systems level. 

OTOH choice of implementation language may well affect rates of
implementation errors.

-- 

David Gillon

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

[Marin David Condic]

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

Can you point to a *single* post in this thread where *anyone* claimed that
writing programs in Ada guaranteed bug-free code?

And you've got it bass-ackwards - they took the range checks *out* because
their analysis indicated the values could *never* exceed valid ranges - so
long as you were in an Arianne 4 flight envelope. Without the range checks,
the math triggered a hardware overflow that the FDA decisions indicated
*must* be a sensor failure because it *couldn't* happen in an Arianne 4
flight envelope. Hence, shut down the channel and switch to the other side.
The software worked as it was designed to work - doing *exactly* what the
programmers wanted it to do - it just wasn't the right thing for Arianne 5.

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/


"Goran Larsson" <hoh@invalid.invalid> wrote in message
news:GHGA3t.Izq@approve.se...
> In article <slrn9mi1q3.7kb.randhol+abuse@kiuk0156.chembio.ntnu.no>,
> Preben Randhol <randhol+abuse@pvv.org> wrote:
>
> > Perhaps read it again.
>
> Why?
>
> The report clearly shows that you can have problematic software in
> any language. It was also ironic that it was a compiler generated
> range check on a value (that was not going to be used) that was the
> event that started the destructive chain of events. The management
> decision that any exception had to be due to hardware error (and
> warranted a shutdown) was _perhaps_ influenced by the belief that
> writing code in Ada resulted in bug free programs. :-)
>
> --
> G�ran Larsson     Senior Systems Analyst    hoh AT approve DOT se

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

[Darren New]

> The following text clearly tells us that the runtime checks (generating
> the exception) were in place at least for this conversion.

Nope. Read the report.
 
> What made the Ariane design team take the view that "software should be
> considered correct until it is shown to be at fault"? Fooled by to much
> trust in Ada?

Read the report. The code was in a device designed for the A4. Nobody
from the A5 looked at the code. 

Somehow, I wouldn't imagine anyone building rockets has a great deal of
blind trust in hardware *or* software.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
          Only a WIMP puts wallpaper on his desktop.

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

[Marin David Condic]

Having been all over that report a number of times and getting grilled by
Lockheed Martin on it personally, I've had more than a little experience
with it. In the first place, if you check the report, I think you'll find
that it states elsewhere that the runtime checks were explicitly removed
because there was a speed constraint that had to be met. The checks were
removed after static analysis indicated that within the Arianne 4 profile,
the numbers would never exceed what was allowed for.

In the second place the "Operand Error" they refer to is *not* a standard
Ada exception and I and others familiar with the report don't know where the
writers extracted this from. However, given the reference to a 64 bit Float
converting to a 16 bit integer and having some familiarity with the
Mil-Std-1750a microprocessor that was the target machine, we concluded that
they were referring to a hardware interrupt that occurs when you perform
that particular conversion instruction. (The report writers were not
software people and were not necessarily conversant in the precise
nomenclature.) This is consistent with the rest of the report's discussion
of what the hardware actually did for FDA.

I think if you re-read the report and possibly some of the additional
commentary you can find on it on the Internet, you may discover that what
I'm saying here is accurate.

As for the "Software should be considered correct..." part? I am in 100%
agreement with you that this is a stupid idea. As for that idea coming from
an Ada culture? I doubt it. I don't know of any Ada engineers who believe
their software is correct because it is written in Ada or make foolish
assumptions that somehow the compiler is going to remove all errors
everywhere. Those of us who have spent years in the realtime, embedded, Ada
world know better than to make that sort of assumption. The Arianne 5
disaster had everything to do with management assuming they could take an
"off the shelf" part designed for one rocket and bolt it onto another rocket
and assuming that it would work correctly without ever having tested it.
That is a stupid assumption for anyone to make - but it gets done all the
time in software and in other disciplines such as mechanical engineering.
Its a management problem - not a language problem.

The disaster didn't have anything to do with the language used to program
the device because the device behaved exactly as it had been designed to do.
It was just outside of its designed environment - the same way that using a
perfectly good tire from a Corvette as one of the tires for a Boeing 747
would be a major disaster.

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/


"Goran Larsson" <hoh@invalid.invalid> wrote in message
news:GHGGJH.JpI@approve.se...
> The following text clearly tells us that the runtime checks (generating
> the exception) were in place at least for this conversion.
>
> | The internal SRI software exception was caused during execution of
> | a data conversion from 64-bit floating point to 16-bit signed integer
value.
> | The floating point number which was converted had a value greater than
> | what could be represented by a 16-bit signed integer. This resulted in
> | an Operand Error. The data conversion instructions (in Ada code) were
not
> | protected from causing an Operand Error, although other conversions of
> | comparable variables in the same place in the code were protected.
>
> What made the Ariane design team take the view that "software should be
> considered correct until it is shown to be at fault"? Fooled by to much
> trust in Ada?
>

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

[Reivilo Snuved]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> In the second place the "Operand Error" they refer to is *not* a standard
> Ada exception and I and others familiar with the report don't know where the
> writers extracted this from. However, given the reference to a 64 bit Float
> converting to a 16 bit integer and having some familiarity with the
> Mil-Std-1750a microprocessor that was the target machine ...

Bzzt. The target machine for Ariane-5 was (and still is) a 68k-series.
Operand Error referred to a FPU exception.

-- 
Olivier Devuns                         | Aonix: http://www.aonix.com

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

[Marin David Condic]

Which target machine? I bet the Arianne 5 has lots of computers on it.

IIRC, this was the Inertial Reference System that had a pair of
Mil-Std-1750a processor boards running identical software. The FDA for
certain classes of errors was to shut down the processor and switch to the
other side. Its been a while since I had to deal with this and I may be
heading into the springtime of my senility, but I recall Lockheed Martin
personnel beating me about the head and shoulders vigorously because my
rocket system had a pair of Mil-Std-1750a's and was being programmed in Ada
and had very similar FDA. They wanted to know if I was going to drop their
billion dollar payload into the ocean with the same error.

So its possible that I am remembering this all wrong. But I can still see
the welts on my back from the beating I took over having an identical
processor and an identical language. Maybe the flogging just addled my mind.

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/


"Reivilo Snuved" <odevuns@iname.JUNK.com> wrote in message
news:stzo9h78kx.fsf@aonix.fr...
>
> Bzzt. The target machine for Ariane-5 was (and still is) a 68k-series.
> Operand Error referred to a FPU exception.
>

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

[Reivilo Snuved]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
[snip]
> 
> So its possible that I am remembering this all wrong. But I can still see
> the welts on my back from the beating I took over having an identical
> processor and an identical language. Maybe the flogging just addled my mind.

Well, you've got it right generally, but I know that the "main" computer
is a 68020 on Ariane-5, and the Inertial (SRI) computers are also of the
68k series. I happen to know this because we provided the Ada compilers
for both. The "main" computer runs a full-Ada runtime, whereas the SRI runs
a "zero-byte" (well, not quite) runtime, the SRI team having their own
"RTOS".

However, the SRI team have recently completed their move to ERC32 (i.e Rad-Hard
SPARC). Starting this fall, all new SRI flight units will be ERC32-based.

-- 
Olivier Devuns                         | Aonix: http://www.aonix.com

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

[Dan Cross]

In article <stzo9h78kx.fsf@aonix.fr>,
Reivilo Snuved  <odevuns@iname.JUNK.com> wrote:
>Bzzt. The target machine for Ariane-5 was (and still is) a 68k-series.
>Operand Error referred to a FPU exception.

Really?  It hardly seems like a commodity microprocessor would be
reliable enough for something that demanding.  Don't get me wrong, the
MC68k series is very, very reliable, but is there really a model which
is designed for the additional stress and interference characteristics
of use on board a space craft?  I'm asking; I'd be very interested if
there were!

	- Dan C.

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

[Reivilo Snuved]

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

> In article <stzo9h78kx.fsf@aonix.fr>,
> Reivilo Snuved  <odevuns@iname.JUNK.com> wrote:
> >Bzzt. The target machine for Ariane-5 was (and still is) a 68k-series.
> >Operand Error referred to a FPU exception.
> 
> Really?  It hardly seems like a commodity microprocessor would be
> reliable enough for something that demanding.  Don't get me wrong, the
> MC68k series is very, very reliable, but is there really a model which
> is designed for the additional stress and interference characteristics
> of use on board a space craft?  I'm asking; I'd be very interested if
> there were!

Well, it IS a 68k aboard Ariane-5. 68020-class. Don't know the exact chip
though.
Remember, the "new" engine controllers for SSMEs are 68k also. 

There's a ESA DASIA proceedings book where the A5 architecture is
described, I'm still trying to locate it however .... :-(


-- 
Olivier Devuns                         | Aonix: http://www.aonix.com

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

[Marin David Condic]

When I was in a different (less well paid) life, we used Mil packaged MC68k
processors on jet engine controls. At some juncture, Motorola told us they
weren't going to make those any more. They were suitable for bolting to the
side of a really hot jet engine - I'm not sure about space.

We used the Mil-Std-1750a because it was (at the time) the only thing RAD
Hard enough to go into deep space - or at least RAD Hard enough and with a
demonstrated record of reliability in deep space. (Gamma rays are considered
"A Bad Thing") I don't know about the MC68k in that environment - if it was
being jettisoned before deep space, then the Mil packaging might have been
sufficient. But I'm not a hardware engineer and I only fake it badly on
newsgroups. :-)

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/


"Dan Cross" <cross@augusta.math.psu.edu> wrote in message
news:9kedbi$fb3@augusta.math.psu.edu...
> In article <stzo9h78kx.fsf@aonix.fr>,
>
> Really?  It hardly seems like a commodity microprocessor would be
> reliable enough for something that demanding.  Don't get me wrong, the
> MC68k series is very, very reliable, but is there really a model which
> is designed for the additional stress and interference characteristics
> of use on board a space craft?  I'm asking; I'd be very interested if
> there were!
>

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

[Mike Silva]

Reivilo Snuved <odevuns@iname.JUNK.com> wrote in message news:<stzo9h78kx.fsf@aonix.fr>...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> 
> > In the second place the "Operand Error" they refer to is *not* a standard
> > Ada exception and I and others familiar with the report don't know where the
> > writers extracted this from. However, given the reference to a 64 bit Float
> > converting to a 16 bit integer and having some familiarity with the
> > Mil-Std-1750a microprocessor that was the target machine ...
> 
> Bzzt. The target machine for Ariane-5 was (and still is) a 68k-series.
> Operand Error referred to a FPU exception.

I've read a lot of speculation that the "Operand Error" in the report
was actually a CPU/FPU exception, but this is the most definitive
statement I've seen.  In this case it seems reasonable to imagine that
the same results would have occurred regardless of the programming
language used.

Mike

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

[Mike Williams]

In article <5267be60.0108030900.26d4a4e7@posting.google.com>,
 mjsilva@jps.net (Mike Silva) writes:
|> I've read a lot of speculation that the "Operand Error" in the report
|> was actually a CPU/FPU exception, but this is the most definitive
|> statement I've seen.  In this case it seems reasonable to imagine that
|> the same results would have occurred regardless of the programming
|> language used.

Perhaps not. In a programming language which supports multiple
task/threads/processes/whatever, it is possible to have a run time
system where failure in one task does not cause failure of the whole
system. In languages with unsafe pointers and without bounds checking,
of course one task can still sabotage another task. You can use an MMU
to prevent this, but we would then be talking of _very_ heavy weight
tasking (maybe what's sometimes called an OS :-).

In Erlang, the whole philosophy of error recovery is that erroneous
tasks (processes) *should* fail. A "link" mechanism allows tasks to
monitor each other, so that a "healthy" task can do "damage
control" if another task should fail. This mechanism of course 
also works accross machine boundaries.

Mind you, I guess that in Ariane-5, the damage was probably already
irrecoverable.........

/m

PS. This is getting somewhat off-track for these newsgroups.

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

[Mike Silva]

mike@erix.ericsson.se (Mike Williams) wrote in message news:<9kemhs$17g$2@news.du.uab.ericsson.se>...
> In article <5267be60.0108030900.26d4a4e7@posting.google.com>,
>  mjsilva@jps.net (Mike Silva) writes:
> |> I've read a lot of speculation that the "Operand Error" in the report
> |> was actually a CPU/FPU exception, but this is the most definitive
> |> statement I've seen.  In this case it seems reasonable to imagine that
> |> the same results would have occurred regardless of the programming
> |> language used.
> 
> Perhaps not. In a programming language which supports multiple
> task/threads/processes/whatever, it is possible to have a run time
> system where failure in one task does not cause failure of the whole
> system. In languages with unsafe pointers and without bounds checking,
> of course one task can still sabotage another task. You can use an MMU
> to prevent this, but we would then be talking of _very_ heavy weight
> tasking (maybe what's sometimes called an OS :-).

Except that the program (all or part) never crashed -- it was in full
control all the way to the end, when it pulled the plug.  My point was
that the hardware exception would have almost certainly been coded to
perform the exact same steps (log the failure, shut down the unit)
regardless of the language used.

Mike

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

[Marin David Condic]

That is exactly the case. The designers took a decision as to the behavior
of the computer in the event of this specific failure. The accommodation was
to shut down the processor and switch to the other side. While other designs
were possible (including multiple tasks that might have let the one side
continue to do *some* of the work) this was not the design they chose. The
decision is not at all uncommon. If you have two parallel computers for
redundancy, you quite often decide that the FDA should be to shut down the
(suspected) bad one and run with the good one. That's exactly why you built
the spare in the first place.

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/


"Mike Silva" <mjsilva@jps.net> wrote in message
news:5267be60.0108051339.6d5f44c9@posting.google.com...
>
> Except that the program (all or part) never crashed -- it was in full
> control all the way to the end, when it pulled the plug.  My point was
> that the hardware exception would have almost certainly been coded to
> perform the exact same steps (log the failure, shut down the unit)
> regardless of the language used.
>

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

[Dan Cross]

In article <GHGGJH.JpI@approve.se>, Goran Larsson <hoh@invalid.invalid> wrote:
>What made the Ariane design team take the view that "software should be
>considered correct until it is shown to be at fault"? Fooled by to much
>trust in Ada?

You apparantly assume that's the case.  Well, you know what they
say when you assume something.

	- Dan C.

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> 
> Can you point to a *single* post in this thread where *anyone* claimed that
> writing programs in Ada guaranteed bug-free code?
> 
> And you've got it bass-ackwards - they took the range checks *out* because
> their analysis indicated the values could *never* exceed valid ranges - so
> long as you were in an Arianne 4 flight envelope. Without the range checks,
> the math triggered a hardware overflow that the FDA decisions indicated
> *must* be a sensor failure because it *couldn't* happen in an Arianne 4
> flight envelope. Hence, shut down the channel and switch to the other side.
> The software worked as it was designed to work - doing *exactly* what the
> programmers wanted it to do - it just wasn't the right thing for Arianne 5.
> 
> MDC
> --
> Marin David Condic

If this is not in an Ada FAQ, it should be.

Warren.

> 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/
> 
> "Goran Larsson" <hoh@invalid.invalid> wrote in message
> news:GHGA3t.Izq@approve.se...
> > In article <slrn9mi1q3.7kb.randhol+abuse@kiuk0156.chembio.ntnu.no>,
> > Preben Randhol <randhol+abuse@pvv.org> wrote:
> >
> > > Perhaps read it again.
> >
> > Why?
> >
> > The report clearly shows that you can have problematic software in
> > any language. It was also ironic that it was a compiler generated
> > range check on a value (that was not going to be used) that was the
> > event that started the destructive chain of events. The management
> > decision that any exception had to be due to hardware error (and
> > warranted a shutdown) was _perhaps_ influenced by the belief that
> > writing code in Ada resulted in bug free programs. :-)
> >
> > --
> > G�ran Larsson     Senior Systems Analyst    hoh AT approve DOT se

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

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

[Scott Ingram]

Goran Larsson wrote:
> 
> In article <slrn9mi1q3.7kb.randhol+abuse@kiuk0156.chembio.ntnu.no>,
> Preben Randhol <randhol+abuse@pvv.org> wrote:
> 
> > Perhaps read it again.
> 
> Why?
> 
> The report clearly shows that you can have problematic software in
> any language. It was also ironic that it was a compiler generated
> range check on a value (that was not going to be used) that was the
> event that started the destructive chain of events. The management
> decision that any exception had to be due to hardware error (and
> warranted a shutdown) was _perhaps_ influenced by the belief that
> writing code in Ada resulted in bug free programs. :-)
> 
> --
> G�ran Larsson     Senior Systems Analyst    hoh AT approve DOT se

I think Ed and Preben's point is that the code in question was
bug free...in the Ariane 4.  I don't think any of us are naive
enough to believe that using language X or toolset Y will save
us from problematic software, but certain languages are better
at reducing certain kinds of errors.  What the Ariane disaster
illustrates best is that even Ada can't overcome bad management
decisions.
-- 
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.

[Ruslan Abdikeev]

People, would you mind to do not cross-post to comp.lang.c++?

Thank you in advance,

Ruslan Abdikeev
VR-1 Entertainment Corp.

"Scott Ingram" <scott@silver.jhuapl.edu> wrote in message
news:3B69901C.23EAF00@silver.jhuapl.edu...
> Goran Larsson wrote:
> >
> > In article <slrn9mi1q3.7kb.randhol+abuse@kiuk0156.chembio.ntnu.no>,
> > Preben Randhol <randhol+abuse@pvv.org> wrote:
> >
> > > Perhaps read it again.
> >
> > Why?
> >
> > The report clearly shows that you can have problematic software in
> > any language. It was also ironic that it was a compiler generated
> > range check on a value (that was not going to be used) that was the
> > event that started the destructive chain of events. The management
> > decision that any exception had to be due to hardware error (and
> > warranted a shutdown) was _perhaps_ influenced by the belief that
> > writing code in Ada resulted in bug free programs. :-)
> >
> > --
> > GО©╫ran Larsson     Senior Systems Analyst    hoh AT approve DOT se
>
> I think Ed and Preben's point is that the code in question was
> bug free...in the Ariane 4.  I don't think any of us are naive
> enough to believe that using language X or toolset Y will save
> us from problematic software, but certain languages are better
> at reducing certain kinds of errors.  What the Ariane disaster
> illustrates best is that even Ada can't overcome bad management
> decisions.
> --
> 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.

[Dan Cross]

In article <GHGA3t.Izq@approve.se>, Goran Larsson <hoh@invalid.invalid> wrote:
>The report clearly shows that you can have problematic software in
>any language. It was also ironic that it was a compiler generated
>range check on a value (that was not going to be used) that was the
>event that started the destructive chain of events. The management
>decision that any exception had to be due to hardware error (and
>warranted a shutdown) was _perhaps_ influenced by the belief that
>writing code in Ada resulted in bug free programs. :-)

I'm afraid that this is inaccurate (as has already been pointed out),
but it also misses the point.  No one ever said you couldn't write bad
code in Ada, but we did point out that it's easier to write good code
in it.

A lot of the arguments I've read in this thread in defense of, eg, C,
are analogous to the argument, ``Well, my friend died in a car crash
even through s/he was wearing a seat-belt, so why should I bother
wearing mine?''  One hopes the answer is self-evident.

	- Dan C.

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

[Larry Kilgallen]

In article <GHGA3t.Izq@approve.se>, hoh@invalid.invalid (Goran Larsson) writes:
> In article <slrn9mi1q3.7kb.randhol+abuse@kiuk0156.chembio.ntnu.no>,
> Preben Randhol <randhol+abuse@pvv.org> wrote:
> 
>> Perhaps read it again.
> 
> Why?
> 
> The report clearly shows that you can have problematic software in
> any language. It was also ironic that it was a compiler generated
> range check on a value (that was not going to be used) that was the
> event that started the destructive chain of events. The management
> decision that any exception had to be due to hardware error (and
> warranted a shutdown) was _perhaps_ influenced by the belief that
> writing code in Ada resulted in bug free programs. :-)

Waking up to the fact that "Hey, I'm on the wrong rocket" certainly
seems a good reason to shut down.  Is there any proof that the rest
of the program would have behaved correctly in the wrong rocket ?

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

[Daniel Fischer]

Hi,

-  followup ("Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam>)

> Waking up to the fact that "Hey, I'm on the wrong rocket" certainly
> seems a good reason to shut down.  Is there any proof that the rest of
> the program would have behaved correctly in the wrong rocket ?

According to ESA, the failure was caused by a conversion of a value from a
64 bit floating point representation to a 16 bit integer representation.
There was no protection against an operand error in this place, while here
was in others.

The value was much higher than expected because the early part of the
trajectory of Ariane 5 differs from that of Ariane 4 and results in
considerably higher horizontal velocity values.

You can read the full report at

	http://www.esa.int/htdocs/tidc/Press/Press96/ariane5rep.html



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.

[Christian Bau]

Daniel Fischer wrote: (Discussing the Ariane failure)
> 
> According to ESA, the failure was caused by a conversion of a value from a
> 64 bit floating point representation to a 16 bit integer representation.
> There was no protection against an operand error in this place, while here
> was in others.
> 
> The value was much higher than expected because the early part of the
> trajectory of Ariane 5 differs from that of Ariane 4 and results in
> considerably higher horizontal velocity values.

Since this thread is about comparing C or C++ and Ada: If the software
had been written in C, C++ or Java, the result would have been a
completely wrong integer result. For example, casting a value of 40000.0
to a 16 bit signed int will give a strange result of -25536. (In Java,
this is defined behaviour. In C or C++ this might be undefined or
implementation defined; in practice the result will most likely be
-25536).

If it is true that this value was indeed never used then the decision to
blow up the rocket was quite unfortunate. But if the value was used,
then it is obvious that this wrong value could cause very bad things to
happen; so blowing up the rocket was indeed correct. 

Why was there no "protection against operand errors"? In other words,
why was there no code that would detect the error, take appropriate
action against the error, and continue flying the rocket? There was of
course a global "protection against unanticipated operand errors": Any
overflow was indeed detected, and anything that comes unanticipated
means that the software doesn't work as planned. Whether this is a
hardware fault or a fault in some programmers logic doesn't really
matter. All you know is that something is wrong, you cannot be sure that
the rocket is doing what it is supposed to do, and this is a very
dangerous situation, so you blow it up. I assume that someone determined
that blowing it up is the least risky thing to do, at least once it is
up in the air. 

I think any explicit check for this overflow and trying to handle it
would have been inappropriate. It was (incorrectly) determined that an
overflow could not happen, so there was no appropriate action possible.
(This is assuming that the results were indeed used. If there is
functionality in a rocket that is not related to its performance, like
sending data to the ground, and a malfunction in this is detected, then
ignoring that malfunction might be the better action).

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

[Daniel Fischer]

Hi,

- followup ("Christian Bau" <christian.bau@isltd.insignia.com>)

> Since this thread is about comparing C or C++ and Ada: If the software
> had been written in C, C++ or Java, the result would have been a
> completely wrong integer result. For example, casting a value of 40000.0
> to a 16 bit signed int will give a strange result of -25536. (In Java,
> this is defined behaviour. In C or C++ this might be undefined or
> implementation defined; in practice the result will most likely be
> -25536).

Nowhere in the report it says "cast". There are appropriate functions in C
and family for conversions of floating point values to integers. 

> Why was there no "protection against operand errors"? In other words,
> why was there no code that would detect the error, take appropriate
> action against the error, and continue flying the rocket?

You didn't even read the report. There was no such code in this place
because there originally was a requirement that only 80% of cpu time could
be used, so they dropped some of the checks.

> I think any explicit check for this overflow and trying to handle it
> would have been inappropriate. It was (incorrectly) determined that an
> overflow could not happen, so there was no appropriate action possible.

You didn't even read the report. The decision that an overflow could not
happen was correct, as the code was written for the Ariane 4 where values
that would cause the conversion to overflow are indeed impossible. The
problem was that this fact was somehow lost and nobody remembered it when
they decided to use the same code for the Ariane 5.

> (This is assuming that the results were indeed used. If there is
> functionality in a rocket that is not related to its performance, like
> sending data to the ground, and a malfunction in this is detected, then
> ignoring that malfunction might be the better action).

The results were not used because there were no results. The overflow
apparently triggered a hardware exception. Since it was determined that
only a hardware defect could cause such an exception, the unit shut itself
down. As did the backup because it got the same data.



Daniel

-- 
IMO, anyway.
end  message by (Daniel Fischer <dan@gueldenland.de>)
clc FAQ:    http://www.eskimo.com/~scs/C-faq/top.html
08/03	Memorial Day of Archbishop Makarios in Cyprus

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

[Christian Bau]

Daniel Fischer wrote:
> 
> > Since this thread is about comparing C or C++ and Ada: If the software
> > had been written in C, C++ or Java, the result would have been a
> > completely wrong integer result. For example, casting a value of 40000.0
> > to a 16 bit signed int will give a strange result of -25536. (In Java,
> > this is defined behaviour. In C or C++ this might be undefined or
> > implementation defined; in practice the result will most likely be
> > -25536).
> 
> Nowhere in the report it says "cast". There are appropriate functions in C
> and family for conversions of floating point values to integers.

In C, the operation of converting a floating point value to a value of
integral type is called a "cast". If they call it different in Ada I
couldn't care less. I would say this demonstrates that you have a very
limited ability of abstraction. 


> > I think any explicit check for this overflow and trying to handle it
> > would have been inappropriate. It was (incorrectly) determined that an
> > overflow could not happen, so there was no appropriate action possible.
> 
> You didn't even read the report. The decision that an overflow could not
> happen was correct, as the code was written for the Ariane 4 where values
> that would cause the conversion to overflow are indeed impossible. The
> problem was that this fact was somehow lost and nobody remembered it when
> they decided to use the same code for the Ariane 5.

This is plain stupid. If code for Ariane 4 is used on Ariane 5, and an
assumption that was true on Ariane 4 is false on Ariane 5, then this is
assumption is false. The assumption that no overflow could happen became
wrong when the code was reused. 

> > (This is assuming that the results were indeed used. If there is
> > functionality in a rocket that is not related to its performance, like
> > sending data to the ground, and a malfunction in this is detected, then
> > ignoring that malfunction might be the better action).
> 
> The results were not used because there were no results. The overflow
> apparently triggered a hardware exception. Since it was determined that
> only a hardware defect could cause such an exception, the unit shut itself
> down. As did the backup because it got the same data.

I think you must be deliberately trying to misunderstand what I wrote.
Yes, if an overflow check makes it impossible to ever use an incorrect
results then incorrect results will not be used. The question is: Would
the result have been used if an overflow had not been detected?

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

[Daniel Fischer]

Hi,

- followup ("Christian Bau" <christian.bau@isltd.insignia.com>)

>> > Since this thread is about comparing C or C++ and Ada: If the
>> > software had been written in C, C++ or Java, the result would have
>> > been a completely wrong integer result. For example, casting a value
>> > of 40000.0 to a 16 bit signed int will give a strange result of
>> > -25536. (In Java, this is defined behaviour. In C or C++ this might
>> > be undefined or implementation defined; in practice the result will
>> > most likely be -25536).
>> 
>> Nowhere in the report it says "cast". There are appropriate functions
>> in C and family for conversions of floating point values to integers.
> 
> In C, the operation of converting a floating point value to a value of
> integral type is called a "cast". If they call it different in Ada I
> couldn't care less. I would say this demonstrates that you have a very
> limited ability of abstraction.

Says someone who states:

> For example, casting a value of 40000.0 to a 16 bit signed int will give
> a strange result of -25536.

In C, the operation of explicitly coercing a floating point value into a
value of an integral type is called a cast. The result is undefined if the
value is outside of the range of the result type. Undefined *includes* an
"operand error", and it also allows for demons to fly out of your nose.
There really is no difference between Ada and C here.

In C, there are also conversion functions (such as lrint) that *can do*
range checking. The report does *not* contain any hint as to the ada
version of a cast being used. It could as well have been the ada version
of such a function.

>> You didn't even read the report. The decision that an overflow could
>> not happen was correct, as the code was written for the Ariane 4 where
>> values that would cause the conversion to overflow are indeed
>> impossible. The problem was that this fact was somehow lost and nobody
>> remembered it when they decided to use the same code for the Ariane 5.
> 
> This is plain stupid. If code for Ariane 4 is used on Ariane 5, and an
> assumption that was true on Ariane 4 is false on Ariane 5, then this is
> assumption is false. The assumption that no overflow could happen became
> wrong when the code was reused.

The assumption that no overflow could happen with Ariane 4 is still true,
even if Ariane 5 was lost due to it. The program was never meant to
control Ariane 5. The mistake was not the assumption that no overflow
could happen but the decision to use the software for a job it was never
meant to do.

>> > (This is assuming that the results were indeed used. If there is
>> > functionality in a rocket that is not related to its performance,
>> > like sending data to the ground, and a malfunction in this is
>> > detected, then ignoring that malfunction might be the better action).

> I think you must be deliberately trying to misunderstand what I wrote.
> Yes, if an overflow check makes it impossible to ever use an incorrect
> results then incorrect results will not be used. The question is: Would
> the result have been used if an overflow had not been detected?

I believe you must be misunderstanding yourself. This is a meaningless
question if the hardware or the implementation of the ada language makes it
impossible not to detect overflow errors, as is the case here.

Also, ignoring *any* malfunction is not a good choice. You can do that on
a personal computer, but not on a rocket where *any* malfunction can mean
that something is seriously messed up. Shuting down a malfunctioning
subsystem is the *only* choice here.


Daniel

-- 
IMO, anyway.
end  message by (Daniel Fischer <dan@gueldenland.de>)
clc FAQ:    http://www.eskimo.com/~scs/C-faq/top.html
08/03	Funeral of King Theoden (LOTR)

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

[Marin David Condic]

The code was not reused any more than you exhibit "code reuse" when you fire
up Microsoft Word for the second time on your computer. They "reused" the
IRS - it was a pseudo-off-the-shelf part that happened to include software
as part of its construction.

This is why the disaster occurred - they presumed that the IRS would work in
the flight envelope of the Arianne 5 without any testing and without any
review of the code or design. Had they done some minimal testing of the unit
within the flight envelope of the Arianne 5, they would have found the
problem and averted disaster.

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/


"Christian Bau" <christian.bau@isltd.insignia.com> wrote in message
news:3B6A6E8A.7D254E26@isltd.insignia.com...
>
> This is plain stupid. If code for Ariane 4 is used on Ariane 5, and an
> assumption that was true on Ariane 4 is false on Ariane 5, then this is
> assumption is false. The assumption that no overflow could happen became
> wrong when the code was reused.
>

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

[Marin David Condic]

"Christian Bau" <christian.bau@isltd.insignia.com> wrote in message
news:3B6A588C.B67A9CF8@isltd.insignia.com...
>
> If it is true that this value was indeed never used then the decision to
> blow up the rocket was quite unfortunate. But if the value was used,
> then it is obvious that this wrong value could cause very bad things to
> happen; so blowing up the rocket was indeed correct.
>
The problem was that the IRS was not needed after the initial launch, so it
should have been shut down. The error was at the hardware level - triggering
an interrupt for an overflow wherein the ISR's designed behavior was to
assume it was the result of flakey hardware, shut down the computer and
transfer control to the other channel. The blowing up of the rocket was done
because it had become unstable in flight - not because the IRS decided to
shut down per se.


> Why was there no "protection against operand errors"? In other words,
> why was there no code that would detect the error, take appropriate
> action against the error, and continue flying the rocket? There was of
> course a global "protection against unanticipated operand errors": Any
> overflow was indeed detected, and anything that comes unanticipated
> means that the software doesn't work as planned. Whether this is a
> hardware fault or a fault in some programmers logic doesn't really
> matter. All you know is that something is wrong, you cannot be sure that
> the rocket is doing what it is supposed to do, and this is a very
> dangerous situation, so you blow it up. I assume that someone determined
> that blowing it up is the least risky thing to do, at least once it is
> up in the air.
>
There was code to detect and react to errors. It worked exactly as it had
been planned to work. There wasn't even a "logic error" - the logic was
perfect given the anticipated use of the device. (Having built similar
systems, I can attest to the fact that when certain errors come up, you have
to make your best guess as to what the cause is likely to be and take some
kind of action that would make sense. This is what the engineers did.)

Remember, the IRS was designed to accommodate the flight envelope of the
Arianne 4 rocket. The situation was such that the normal Ada constraint
checks were removed to gain needed speed. This was done *after* an analysis
indicated that any numbers big enough to trigger the constraint checks (or
the hardware overflow) would have to be wildly out of the possible range of
the Arriane 4 flight envelope. The engineers who designed it basically said
"If a hardware overflow occurs at this point, that's O.K. It means a sensor
has gone bad and when we trap the interrupt, we will shut down the bad
channel and switch to the good one." Having Ada constraint checks probably
wouldn't have changed this any since the likely decision would be "If we got
a Constraint_Error in this routine, it means a bad sensor so shut down the
channel and transfer to the other side."

The problem was that basically, the FDA was correct for the Arianne 4 - a
failure of a sensor would be detected and accommodated by a transfer of
control to the other channel. It was just the *wrong* FDA for the Arianne 5
since an overflow of that computation would be an expected condition given
the flight envelope. Hence, the software would probably have been designed
to do the calculations differently, allowing for the larger values.

They *never* tested the IRS against the Arianne 5 flight envelope. If they
did so, it would have triggered the error and they would have known they had
a problem.

> I think any explicit check for this overflow and trying to handle it
> would have been inappropriate. It was (incorrectly) determined that an
> overflow could not happen, so there was no appropriate action possible.
> (This is assuming that the results were indeed used. If there is
> functionality in a rocket that is not related to its performance, like
> sending data to the ground, and a malfunction in this is detected, then
> ignoring that malfunction might be the better action).

No, it was *correctly* determined that an overflow could never happen -
within the flight path of the Arianne 4 and so long as the sensors were
functioning correctly. If the overflow *did* occur, it meant you had a
problem with the computer or the sensors. Go into FDA because something is
broke.

It was an *incorrect* design for the Arianne 5. Nobody ever determined that
because nobody ever looked. They just took the IRS off the shelf, bolted it
to the Arriane 5 and assumed it would work as flawlessly as it did in the
Arianne 4. The problem wasn't a language issue or even a design issue - it
was a management issue for failing to determine that a specific part was/was
not suited for a new application.

I hope this clears things up a little. There always seems to be a lot of
misunderstanding of exactly what went on in this disaster and wherein the
problems came up.

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/

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

[Tor Rustad]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message

> There was code to detect and react to errors. It worked exactly as it had
> been planned to work. There wasn't even a "logic error" - the logic was
> perfect given the anticipated use of the device. (Having built similar
> systems, I can attest to the fact that when certain errors come up, you
> have
> to make your best guess as to what the cause is likely to be and take some
> kind of action that would make sense. This is what the engineers did.)

Not quite, it's with high probability a *wrong* conclusion to assume
simultanouse HW fault in duplicated/independent HW.

As an analogy to the IRS design, cryptographers do design "secure"
cryptosystems, which may even be proven correct by formal methods. In the
real world it'is still broken, why?

One reason can be a change in the environment, [1] discuss this subject and
gives an interesting example from a cash machine fraud in Holland
(1993-1994). Here, one person wire-tapped the communication between a card
reader and the controlling PC, and aswell captured the PIN by just looking.

The change in the environment in this case, was that back when the standards
for magnetic cards where designed, it was assumed that the card would only
be read in a secure environment (e.g. ATM) and the content of the magnetic
stripe was not a secret (as the PIN was). The orginal designers didn't
forsee
the usage of untrusted devices, and nobody in the industry saw this
environment change (it happend over multiple years).

<good stuff snipped>

> I hope this clears things up a little. There always seems to be a lot of
> misunderstanding of exactly what went on in this disaster and wherein the
> problems came up.

Yes. Interesting reading.

[1] "Security Engineering" by Ross Anderson.
--
Tor <torust AT online DOT no>
"I was a relative latecomer.  The earliest date that I am sure I was posting
news was in 1984, but it might have been as early as two years before
that".  - Chris Torek, comp.lang.c 2001-08-02.

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

[Marin David Condic]

"Tor Rustad" <torust@online.no.spam> wrote in message
news:ypTa7.3739$e%4.109795@news3.oke.nextra.no...
>
> Not quite, it's with high probability a *wrong* conclusion to assume
> simultanouse HW fault in duplicated/independent HW.
>
I don't know where you got the idea I said it was correct to assume
simultaneous HW fault in duplicated/independent HW. If anything, I was
stating that this was the *correct* design given that it is not very likely
that the sensors on *both* channels would simultaneously go bad. (If they
do, you're screwed anyway and your rocket is going in the ocean and there
isn't anything I can do about it with software.) Hence, detecting that a
sensor value is way out of any sane and reasonable range might be sufficient
grounds to shut down the bad channel and switch to the other side.

FDA is a very tricky business, so it is hard to second-guess the decisions
that were taken in this regard without full knowledge of all the hardware
and software issues. I'd be inclined to believe that the original designers
knew what they were doing in designing that FDA.

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

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

[Darren New]

> Waking up to the fact that "Hey, I'm on the wrong rocket" certainly
> seems a good reason to shut down.  Is there any proof that the rest
> of the program would have behaved correctly in the wrong rocket ?

Since it was *supposed* to have been shut down before the rocket even
left the pad on the A5, one would be led to assume yes.

followups redirected.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
          Only a WIMP puts wallpaper on his desktop.

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

[CBFalconer]

Goran Larsson wrote:
> 
> In article <slrn9mi1q3.7kb.randhol+abuse@kiuk0156.chembio.ntnu.no>,
> Preben Randhol <randhol+abuse@pvv.org> wrote:
> 
> > Perhaps read it again.
> 
> Why?
> 
> The report clearly shows that you can have problematic software in
> any language. It was also ironic that it was a compiler generated
> range check on a value (that was not going to be used) that was the
> event that started the destructive chain of events. The management
> decision that any exception had to be due to hardware error (and
> warranted a shutdown) was _perhaps_ influenced by the belief that
> writing code in Ada resulted in bug free programs. :-)

And you are claiming that people with such poor thinking would
produce better software in equal time using a language without
compile and run time checks? :-)

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

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

[James Rogers]

Tor Rustad wrote:
> 
> "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> > 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?

Let's get past generalities and talk facts here. Ada provides run time
checking. It also provides the ability to eliminate the run time
checking. The part of the Ariane 5 code that cause the problem had its
run time checking removed. This results in performance undistinguishable
from code generated by languages with no ability to automatically
produce run time checking.

The code had been tuned for performance. The problems encountered
had no basis in poor performance. The problems were caused by a
faulty software reuse process.

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

Again, Java's slow performance is not an issue of the language. It is
an issue of the run time environment. If you were to implement the
Java machine in hardware, instead of using a virtual machine, then
Java performance would be as fast as C. Java's performance real
performance problems begin with the fact that Java only runs on one
target. That target is emulated on most hardware. Software
emulation of hardware always produces performance problems.

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

I see now that you are admitting that performance is not controlled
by the language. Implementations and environment may play a roll.

Given your analysis of performance related to languages I could
state that C programs are clearly slower than Ada programs with
run time checking turned on. How can this be so? Easy.

Ada provides efficient built in support for concurrency. C does not.
Therefore, the most common and natural design for a C program is
single threaded. On the other hand, it is very common to have a
multi-threaded Ada program. Given a common platform, such as a PC
running a Win 32 operating system, I could easily build an Ada
program with multiple threads implementing a socket server, that
would blow away any single threaded C implementation. I could do
this with all run time checks enabled in Ada, and all optimizations
enabled in C.

Which language is faster? The answer still cannot be given. You
can only measure specific implementations, not languages
themselves.

Jim Rogers
Colorado Springs, Colorado USA

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

[Tor Rustad]

[snipped comp.lang.c++,comp.lang.functional]

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> Tor Rustad wrote:

> Given your analysis of performance related to languages I could
> state that C programs are clearly slower than Ada programs with
> run time checking turned on. How can this be so? Easy.
>
> Ada provides efficient built in support for concurrency. C does not.

Right, however strictly conforming C programs are rare beasts in real life.
For
example sockets are no more part of ISO C than e.g. POSIX pthreads are!

> Therefore, the most common and natural design for a C program is
> single threaded. On the other hand, it is very common to have a
> multi-threaded Ada program. Given a common platform, such as a PC
> running a Win 32 operating system, I could easily build an Ada
> program with multiple threads implementing a socket server, that
> would blow away any single threaded C implementation.

<off-topic>
Just for the record, sockets has support for non-blocking I/O, and a single
threaded server may very well run faster than a multi-threaded server. Also,
I think the most common server design by C programmers (on Win32) is to use
multi-threading, and using a lot of *context* switching. :-)
</off-topic>

--
Tor <torust AT online DOT no>
"Dijkstra probably hates me" - Linus Torvalds

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

[Larry Kilgallen]

In article <xpTa7.3738$e%4.109789@news3.oke.nextra.no>, "Tor Rustad" <torust@online.no.spam> writes:
> "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.

If you aspire to compare the speed of two languages, you must do so
for equivalent programs.  That means, at the gross level:

	Compare a default Ada program to a C program that has
		hand-coded checks everywhere Ada inserts checks.

   or:
	Compare a default C program to an Ada program which has
		checks suppressed.

Otherwise the features of the two programs are not the same.

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

[Richard Bos]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:

> If you aspire to compare the speed of two languages, you must do so
> for equivalent programs.  That means, at the gross level:
> 
> 	Compare a default Ada program to a C program that has
> 		hand-coded checks everywhere Ada inserts checks.

Erm, no. The standard C way is not to check every bound, every time.
Correct procedure is to design your program such that you _prevent_
errors rather than detecting them as they occur; for example, input is
checked _once_, and then, if it passes the tests, assumed correct. You
don't go checking it every time you use it.
If you wish to claim this is not equivalent, very well; but you can't go
around claiming that C is bad simply because it doesn't do things the
Ada way.

Richard

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

[Dan Cross]

In article <3b6e9c33.1478392360@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>Erm, no. The standard C way is not to check every bound, every time.
>Correct procedure is to design your program such that you _prevent_
>errors rather than detecting them as they occur; for example, input is
>checked _once_, and then, if it passes the tests, assumed correct. You
>don't go checking it every time you use it.

But, what if the input changes?  What if for some reason your
verification procedure was incorrect, and something slipped through?
Case in point:  do you ever call atoi?  What does it return when passed
invalid input?  I know it's supposed to be undefined, but most
implementations will just return zero; how do you distinguish this from
valid input?  Sure you can say, ``well, you should never use atoi(),
prefering instead to use strtol()'' but that's only a contrived example
and I could come up with more, as I'm sure every reasonably competent
C programmer could.  And that's my point.

And why on earth would I want to code yet another generation purpose
dictionary ADT?  Hashing?  Please!

>If you wish to claim this is not equivalent, very well; but you can't go
>around claiming that C is bad simply because it doesn't do things the
>Ada way.

No one is saying that.

No one is even saying that C is bad.

What we are saying is that it's not the appropriate tool for all problems.

Just like a hammer isn't the appropriate tool for all problems (since
someone found an example of screws you do hammer in, how about using a
hammer as a wrench?  :-).

	- Dan C.

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

[Ted Dennison]

In article <oUlfbxsKs1+d@eisner.encompasserve.org>, Larry Kilgallen says...
>If you aspire to compare the speed of two languages, you must do so
Then you aspire to make a meaningless comparison.

>for equivalent programs.  That means, at the gross level:
>
>	Compare a default Ada program to a C program that has
>		hand-coded checks everywhere Ada inserts checks.
>
>   or:
>	Compare a default C program to an Ada program which has
>		checks suppressed.

The speed you are going to see out of this result is going to have way more to
do with the compiler writers than it does the language. For instance, if I took
your same C algorithm, recoded it in Ada, then compiled the C using VC++ and the
Ada using my GreenHills compiler, which is meant for embedded PC targets and has
oodles of optimization options, then there's a very good chance the Ada will end
up faster. On the other hand, if I use the ObjectAda Win32 compiler for the Ada
code, and GreenHills' embedded C compiler, there's a good chance the C would run
faster. The only thing that would be proven by this is that Green Hills cares a
lot more about code optimization that Windows compilers do.

You *can't* compare language speed in a vaccum. You can only compare
*compilers*, which have many variables to their generated code speed besides the
input language.

The closest you can probably come is to try it using GCC, since they share a
back-end (or at least, they do if you use gnat's GCC for the C compiles too).
But even that's a bit unfair, as GCC's optimization capabilities are built
around what C can provide, and it doesn't try to use any of the extra info that
Ada provides to optimizers. Nonetheless, there is at least one instance of
someone doing this and actually getting the *same executable* from both.

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

[Larry Kilgallen]

In article <3b6e9c33.1478392360@news.worldonline.nl>, info@hoekstra-uitgeverij.nl (Richard Bos) writes:
> Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> 
>> If you aspire to compare the speed of two languages, you must do so
>> for equivalent programs.  That means, at the gross level:
>> 
>> 	Compare a default Ada program to a C program that has
>> 		hand-coded checks everywhere Ada inserts checks.
> 
> Erm, no. The standard C way is not to check every bound, every time.
> Correct procedure is to design your program such that you _prevent_
> errors rather than detecting them as they occur; for example, input is
> checked _once_, and then, if it passes the tests, assumed correct. You
> don't go checking it every time you use it.
> If you wish to claim this is not equivalent, very well; but you can't go
> around claiming that C is bad simply because it doesn't do things the
> Ada way.

I did not claim that at all.  I did say that if one wishes to compare
the speed of code from compilers for two different languages one must
write equivalent programs.  Saying "take the default" for two different
products is nonsense, just as much as you starting my copy of Netscape
and expecting the screen will be the same as on your copy.

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.

[Richard Bos]

Ted Dennison<dennison@telepath.com> wrote:

> compiler. Remember, "printf" actually has to stop and interpret the input string
> to look for replacements.

No, it doesn't; not unless the format string isn't a constant.

Richard

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

[Yoann Padioleau]

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

info@hoekstra-uitgeverij.nl (Richard Bos) writes:

> Ted Dennison<dennison@telepath.com> wrote:
> 
> > compiler. Remember, "printf" actually has to stop and interpret the input string
> > to look for replacements.
> 
> No, it doesn't; not unless the format string isn't a constant.
Yes it does. The source code from printf is in the C library, so the compiler
cant optimise code such as 'printf("%d    %f   %s",i,f,str)', he cant
generate print_int(i);print_space(4);print_float(f);....
This is called partial evaluation, and in practice it is hard to put
in a compiler.



> Richard

-- 
Yoann  Padioleau,  INSA de Rennes, France,   http://www.irisa.fr/prive/padiolea
Opinions expressed here are only mine. Je n'�cris qu'� titre personnel.
**____   Get Free. Be Smart.  Simply use Linux and Free Software.   ____**

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

[Matthias Blume]

Yoann Padioleau wrote:
> 
> info@hoekstra-uitgeverij.nl (Richard Bos) writes:
> 
> > Ted Dennison<dennison@telepath.com> wrote:
> >
> > > compiler. Remember, "printf" actually has to stop and interpret the input string
> > > to look for replacements.
> >
> > No, it doesn't; not unless the format string isn't a constant.
> Yes it does. The source code from printf is in the C library, so the compiler
> cant optimise code such as 'printf("%d    %f   %s",i,f,str)', he cant
> generate print_int(i);print_space(4);print_float(f);....

Sure it can.  It is explicitly permitted for things like <stdio.h> and
everything defined there to be "special" so that a compiler can optimize
them.  Generating optimized code for calls of printf that have a constant
format string does not require the compiler to look at the executable code
of printf that is in the library.  It just has to have built-in knowledge
of what printf is supposed to do.

It's just like us humans: When I see "fprintf(f, "%s", foo)" in a C program,
I _know_ that I can replace it with "fputs (foo, f)".  And I know this without
looking at the code for fprintf, without partially applying it to "%s".

Matthias

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

[Aaron Denney]

On 06 Aug 2001 17:02:55 +0200, Yoann Padioleau <padiolea@merlin.irisa.fr> wrote:
> info@hoekstra-uitgeverij.nl (Richard Bos) writes:
> > Ted Dennison<dennison@telepath.com> wrote:
> > > compiler. Remember, "printf" actually has to stop and interpret
> > > the input string to look for replacements.
> > 
> > No, it doesn't; not unless the format string isn't a constant.
>
> Yes it does. The source code from printf is in the C library, so the compiler
> cant optimise code such as 'printf("%d    %f   %s",i,f,str)', he cant
> generate print_int(i);print_space(4);print_float(f);....
> This is called partial evaluation, and in practice it is hard to put
> in a compiler.

In a C compiler, sure.  This is also posted to comp.lang.functional
and many compilers for functional languages will do partial evaluation
at compile-time routinely.

-- 
Aaron Denney
-><-

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

[Aaron Denney]

On Mon, 06 Aug 2001 14:17:47 GMT, Ted Dennison <dennison@telepath.com> 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).

[reformatted]

fputs() does not scan for '%', only the NUL character.  If you wanted
to be slightly less portable write() is also an option.

-- 
Aaron Denney
-><-

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

[Mike Silva]

"Tor Rustad" <torust@online.no.spam> wrote in message news:<cOHa7.3620$e%4.107328@news3.oke.nextra.no>...
> "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).

I certainly agree that having the primary unit shut down when the
secondary unit had already shut down was not smart.
 
> 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).

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

I have seen hints that it was simply for telemetry.  Maybe somebody
has better knowledge.
 
Mike

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

[David Gillon]

Tor Rustad wrote:

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

It's not quite that simple. An argument can be made that because the
requirements for any critical system must necessarily be the same across
each of the redundant channels the design decisions and implementations
will strongly parallel each other no matter how independent the teams.
In that case you may be better off with a single implementation team,
single potential source of errors and more effort dedicated to finding
them.

There are also at least two different sorts of redundancy used in
critical systems. In one there is a single live channel with one or more
channels in the background ready to replace it if an error is
discovered. In the other multiple channels are live at the same time and
negotiate the action to be taken amongst themselves. In this second case
the extremely close coupling of the channels pretty much demands a
single set of requirements/code/design.

-- 

David Gillon

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

[Marin David Condic]

"Tor Rustad" <torust@online.no.spam> wrote in message
news:cOHa7.3620$e%4.107328@news3.oke.nextra.no...
>
> 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).
>
That is *extremely* expensive to do and doesn't guarantee that you won't
still have problems. Yes, identical software on both sides allows for a
common-mode failure. But if you had different software on both sides, you
could still have common-mode failure for the duplicate processors. Use
different processors? Then you can still have common-mode failure because of
common requirements or common design decisions. Don't forget that by having
duplicate design efforts you also have doubled the chances that someone
introduces an error into the design. Failure of one side can be just as
disasterous as failure of both sides depending on the failure mode. In fact
these sort of systems have been built, but I don't know that they have any
significantly better reliability than dual-redundant duplicate designs.


> 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.
>
Ada is just as fast as any other programming language. That's not the issue.

If you've ever worked with this sort of embedded system you might have an
appreciation for the fact that the *real* limit was the speed of the
processor. And that you sometimes can't change it for a whole variety of
reasons. You are often trying to squeeze a whole bunch of functionality into
very tight timing loops and you really bend every effort to get the optimal
performance out of it and if your compiler was generating inefficient code
for this, you'd dip into assembler. I wouldn't question what the designers
did in terms of optimization or selection of numeric sizes, etc., because
there is no indication that they did anything wrong here. They knew they had
a timing problem. They optimized their code to solve it. They did an
analysis to make sure it was correct. They selected appropriate
accommodations in the event of failures. It worked flawlessly in the
anticipated environment.

Could they have come up with a better design? Almost certainly. Given enough
cubic dollars and an eternity in which to do it, they probably could have
come up with something more efficient, less likely to fail, etc. But in real
world engineering that is often not possible. They came up with something
that was "good enough" for the job at hand. The problem arose when their
device was used in an application for which it wasn't designed.

> > 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.
>
Well, true enough. But remember that they were basically taking an
off-the-shelf product and bolting it on to a new application. This was
hardly the fault of the original design engineers. It was the fault of bad
management decisions in deciding to "reuse an old design" that had a proven
track record and *assuming* that it would work correctly in the new
application.

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/

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

[CBFalconer]

Marin David Condic wrote:
> 
> "Tor Rustad" <torust@online.no.spam> wrote in message
> news:cOHa7.3620$e%4.107328@news3.oke.nextra.no...
> >
... snip ...
> >
> > 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.
> >
> Well, true enough. But remember that they were basically taking an
> off-the-shelf product and bolting it on to a new application. This was
> hardly the fault of the original design engineers. It was the fault of bad
> management decisions in deciding to "reuse an old design" that had a proven
> track record and *assuming* that it would work correctly in the new
> application.

I don't think that is correct.  As I read this thread, the problem
was in the documentation of the module.  That should have stated,
somewhere, "This module is specific to the Arianne 4 flight
path".  Possibly, at some point it was not, but once the
specificity went in so should have the documentation annotation.

To quote a famous actor "you gotta know your limitations".

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

[Marin David Condic]

This is implying that the software itself was reviewed to check its
limitations. It was not. Reread the report. They took an IRS that was
designed for and used on the Arianne 4 and used it on the Arianne 5 without
testing it in the new flight envelope. It wasn't a case of downloading some
utility software from the Internet and recompiling it for a new system or
some similar software-reuse scenario. This was an *embedded*
computer*system* that had software as one of its "parts" and nobody tested
the "part" to see if it was strong enough to hold an Arianne 5. It is
roughly analogous to your purchasing a VCR that has embedded computer
software to drive the buttons, etc., and plugging it in to an entirely new
video source.

Don't trust this thread to give you an accurate picture of what went on in
the disaster. There is a lot of misinformation, conjecture, theorizing, etc.
that is not based on an understanding of the Inertial Reference System in
question or how it was used or how hardware of this type is typically built,
etc. Read the report. Read some of the commentary about the report from
people who should know something about rockets, etc. It is not the situation
that many people imagine it to be or try to wishfully think it into being.
It is *definitely* not a case where someone was charged with reviewing some
code and didn't see an appropriate comment in the module banner. Nobody
reviewed, analyzed or tested *anything* prior to its first use on the
Arianne 5.

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/


"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:3B6ED4FF.F3A9D29F@yahoo.com...
>
> I don't think that is correct.  As I read this thread, the problem
> was in the documentation of the module.  That should have stated,
> somewhere, "This module is specific to the Arianne 4 flight
> path".  Possibly, at some point it was not, but once the
> specificity went in so should have the documentation annotation.
>
> To quote a famous actor "you gotta know your limitations".
>

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

[Ed Falis]

Goran Larsson wrote:
> 
> In article <3B687EDF.9359F3FC@mediaone.net>,
> Ed Falis  <efalis@mediaone.net> wrote:
> 
> > Read the report.
> 
> I have. Your point is?
> 
> --
> G�ran Larsson     Senior Systems Analyst    hoh AT approve DOT se

It was about inappropriately reused code.  I suppose that does bolster
some of the arguments about poor programming, though the error in this
case was due to decisions pretty far upstream from the code.

- Ed

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

[Marin David Condic]

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

A very deliberate decision was taken to remove the safety checks (which may
not have saved anything anyway - it was a question of proper FDA.) in order
to gain needed performance. A static analysis was done that insured the code
was correct for the Arianne 4 flight envelope. It worked successfully in
that environment. Moving it to the Arianne 5 was done without any review of
those issues and nothing was done to test the unit in the new flight
envelope.

In other words, the software did *precisely* what it was designed to do - it
was just too bad that what it was designed to do wasn't the right thing to
do.

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/


"Ed Falis" <efalis@mediaone.net> wrote in message
news:3B694F80.C7C2D013@mediaone.net...
> Goran Larsson wrote:
> >
> > In article <3B687EDF.9359F3FC@mediaone.net>,
> > Ed Falis  <efalis@mediaone.net> wrote:
> >
> > > Read the report.
> >
> > I have. Your point is?
> >
> > --
> > G�ran Larsson     Senior Systems Analyst    hoh AT approve DOT se
>
> It was about inappropriately reused code.  I suppose that does bolster
> some of the arguments about poor programming, though the error in this
> case was due to decisions pretty far upstream from the code.
>
> - Ed

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

[Reivilo Snuved]

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

Ed Falis <efalis@mediaone.net> writes:

> Goran Larsson wrote:
> > 
> > In article <3B687EDF.9359F3FC@mediaone.net>,
> > Ed Falis  <efalis@mediaone.net> wrote:
> > 
> > > Read the report.
> > 
> > I have. Your point is?
> > 
> > --
> > G�ran Larsson     Senior Systems Analyst    hoh AT approve DOT se
> 
> It was about inappropriately reused code.  I suppose that does bolster
> some of the arguments about poor programming, though the error in this
> case was due to decisions pretty far upstream from the code.
> 
> - Ed

Wasn't there, also,  a program management decision  NOT to perform a
(arguably long/costly) integrated test, which would have revealed the error ?
 - it did indeed, when it was performed ... after the flight. 

-- 
Olivier Devuns                         | Aonix: http://www.aonix.com

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

[Ted Dennison]

In article <%CX97.14134$ar1.47393@www.newsranger.com>, Ted Dennison says...
>
>>"Mike Smith" <smithmc@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpmb575l80@corp.supernews.com>...
>>> 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

>If you don't think this is a big problem, check out this cracker website, which
>is dedicated to teaching young script kiddies how to exploit Windows Buffer
>Overflows: http://www.cultdeadcow.com/cDc_files/cDc-351/
>My own company blocks it, but I understand it is titled: "The Tao of Windows
>Buffer Overflow". :-)

I found a mirror which folks like me behind facist firewalls may have an easier
time accessing. http://www.supportamerica.com/win_buff/win_buff_overflow.html .
If you don't understand the buffer overflow problem (which apparently, at least
Mike doesn't), its a highly reccomended read. They even come out and say that
there are languages that don't have this problem, but Microsoft was too lazy to
use one of them (a rough paraphrase of their words).

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

[Mike Smith]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:L5Y97.14163$ar1.47661@www.newsranger.com...
>
> I found a mirror which folks like me behind facist firewalls may have an
easier
> time accessing.
http://www.supportamerica.com/win_buff/win_buff_overflow.html .
> If you don't understand the buffer overflow problem (which apparently, at
least
> Mike doesn't)

Yes, I do.  However, what I also understand is that buffer overflow problems
are a *bug*, not a "feature", and they are a bug in the *application code*,
not the language.  Only improperly written C code can contain buffer
overflow problems, and there is absolutely *no* excuse for finding them in
C++ code, because the STL can be used to eliminate them completely.

--
Mike Smith

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

[Dale Stanbrough]

Mike Smith wrote:

> Yes, I do.  However, what I also understand is that buffer overflow problems
> are a *bug*, not a "feature", and they are a bug in the *application code*,
> not the language.  Only improperly written C code can contain buffer
> overflow problems, and there is absolutely *no* excuse for finding them in
> C++ code, because the STL can be used to eliminate them completely.


Ah, that's the solution! Lets just write -proper- code.

Chain saw guards - not needed, just use them properly!
Seat belts - not needed, just drive properly!
Languages with checks - not needed - just code properly!
Condoms ..., er, um....

Dale :-)

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

[Kaz Kylheku]

In article <dale-8EE262.08123502082001@mec2.bigpond.net.au>, Dale
Stanbrough wrote:
>Mike Smith wrote:
>
>> Yes, I do.  However, what I also understand is that buffer overflow problems
>> are a *bug*, not a "feature", and they are a bug in the *application code*,
>> not the language.  Only improperly written C code can contain buffer
>> overflow problems, and there is absolutely *no* excuse for finding them in
>> C++ code, because the STL can be used to eliminate them completely.
>
>
>Ah, that's the solution! Lets just write -proper- code.
>
>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?

>Languages with checks - not needed - just code properly!

An analogy for this is the use of video cameras to prevent crime.
In reality, cameras only displace crime to location without cameras.

Languages with checks are great, but they don't compensate for bad
programming.  What they do is displace bad programming. Programmers
are displaced to causing other types of errors, or maybe they are
displaced to other programming languages entirely.

If programs in some language tend to demonstrate more robustness than
programs in some other language, is it due to the language, or is it
due to the types of people that gravitate toward using these languages?

I suspect that if Microsoft wrote IIS in Caml, Lisp or Ada, using the same
developers, it would still have security holes. They would not be the
same holes, revolving around the injection of a machine language through
a buffer overflow, but I'm sure they could figure out some creative
ways of screwing up.

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

[Dale Stanbrough]

Kaz Kylheku wrote:

> Languages with checks are great, but they don't compensate for bad
> programming.

Well, I suspect that this is purely conjecture on your part. My equally
valid conjecture (actually possibly better, because I've seen lots
of students use C and Ada) is that better languages do result in 
better code. Errors in code (such as array overflow) is removed. 
The code that is produced generally has fewer of these problems 
(because they are picked up earlier, and are removed from
the program).

Perhaps I should ask you this question...

   Would you be happy if the C language went back to not 
   enforcing/type checking parameters to functions?



What they do is displace bad programming. Programmers
> are displaced to causing other types of errors, or maybe they are
> displaced to other programming languages entirely.

Again this is simply conjecture, with I would guess, little evidence.


> If programs in some language tend to demonstrate more robustness than
> programs in some other language, is it due to the language, or is it
> due to the types of people that gravitate toward using these languages?

Why are you asking this question, if above you state that such
languages -don't- compensate for bad programming? I don't think
you can have it both ways...

Dale

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

[Warren W. Gay VE3WWG]

Dale Stanbrough wrote:
> Kaz Kylheku wrote:
> > Languages with checks are great, but they don't compensate for bad
> > programming.
> 
> Well, I suspect that this is purely conjecture on your part. My equally
> valid conjecture (actually possibly better, because I've seen lots
> of students use C and Ada) is that better languages do result in
> better code. Errors in code (such as array overflow) is removed.
> The code that is produced generally has fewer of these problems
> (because they are picked up earlier, and are removed from
> the program).
> 
> Perhaps I should ask you this question...
> 
>    Would you be happy if the C language went back to not
>    enforcing/type checking parameters to functions?

I have programmed in "B" ages ago, and it was virtually typeless
(there was a distinction made for floating point values). I can
tell you, the only thing that was worse to debug, was assembly
language! Everything (but floats) were a word (on the Honeywell,
that was a 36-bit word). To work with strings you did procedure
calls... what a nightmare to debug.

When C came along, it was a blessing. Why? Stronger type checking
and other "language safeguards".

But today, C is the "B" of yesteryear. Ada is a big improvement
over C, even C++ and yes, Java.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Brian Rogoff]

On Thu, 2 Aug 2001, Warren W. Gay VE3WWG wrote:
> Dale Stanbrough wrote:
> > Perhaps I should ask you this question...
> > 
> >    Would you be happy if the C language went back to not
> >    enforcing/type checking parameters to functions?
> 
> I have programmed in "B" ages ago, and it was virtually typeless
> (there was a distinction made for floating point values). I can
> tell you, the only thing that was worse to debug, was assembly
> language! Everything (but floats) were a word (on the Honeywell,
> that was a 36-bit word). To work with strings you did procedure
> calls... what a nightmare to debug.
> 
> When C came along, it was a blessing. Why? Stronger type checking
> and other "language safeguards".
> 
> But today, C is the "B" of yesteryear. Ada is a big improvement
> over C, even C++ and yes, Java.

You know, I agree with you. Strong static type systems are a good thing. 
I tried Ada 95 and did find it more productive than C or C++ when you
factor out the library advantages of C and C++. Still, I write C far more 
than Ada and I don't see that changing for a while, unfortunately. 

If you look at the newsgroups in the distribution list, you'll see that
this troll was crossposted to comp.lang.functional. Many people who read
that (this?) list probably wouldn't argue about your statement, but would 
say "so what?". Couldn't you take the next step and say Ada is now like 
B on account of more advanced languages like SML, Haskell, Mercury, and
OCaml? Or, would you argue that type inference has deleterious effects 
on program readability and maintainability? 

Anyways, I bet someone could take a trimmed down Ada, maybe the SPARK 
subset, and make a pretty slick little pseudo functional language with a 
sophisticated type system, along the lines of what the Cyclone project at 
Cornell does with C. 

-- Brian

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

[Richard Bos]

Dale Stanbrough <dale@cs.rmit.edu.au> wrote:

>    Would you be happy if the C language went back to not 
>    enforcing/type checking parameters to functions?

No. Because checking parameter passing can be done, and takes time only,
at compile-time. Checking array bounds has an impact on the performance
of the program itself.
Oh, btw, there _are_ bounds-checking compilers for C. They get used
where the extra safety is deemed important enough to justify the loss of
speed.

Richard

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

[Martin Dowie]

FYI

1) you can always turn these checks "off" for speed
2) there are constructs that will allow the compiler
   to not insert them in the first place (e.g. using
   <type_name>'Range when looping through an array
   indexed by <type_name>

From what I remember of a Tucker Taft message a while
back there are considerations of making even more
checks compiler-time as opposed to run-time in Ada0Y
(e.g. some of the elaboration checks).

Richard Bos <info@hoekstra-uitgeverij.nl> wrote in message
news:3b690549.1112022840@news.worldonline.nl...
> Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
>
> >    Would you be happy if the C language went back to not
> >    enforcing/type checking parameters to functions?
>
> No. Because checking parameter passing can be done, and takes time only,
> at compile-time. Checking array bounds has an impact on the performance
> of the program itself.
> Oh, btw, there _are_ bounds-checking compilers for C. They get used
> where the extra safety is deemed important enough to justify the loss of
> speed.
>
> Richard

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

[Richard Bos]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote:

[ Learn to post, damn it. And learn to snip. ]

> Richard Bos <info@hoekstra-uitgeverij.nl> wrote in message
> news:3b690549.1112022840@news.worldonline.nl...
> > Oh, btw, there _are_ bounds-checking compilers for C. They get used
> > where the extra safety is deemed important enough to justify the loss of
> > speed.
>
> 1) you can always turn these checks "off" for speed
> 2) there are constructs that will allow the compiler
>    to not insert them in the first place (e.g. using
>    <type_name>'Range when looping through an array
>    indexed by <type_name>

Kinda defeat the point of the Original Troll, don't they, though?

Richard

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

[Martin Dowie]

Richard Bos <info@hoekstra-uitgeverij.nl> wrote in message
news:3b6a47b6.1194575915@news.worldonline.nl...
[snip expletive :0)]
> > 1) you can always turn these checks "off" for speed
> > 2) there are constructs that will allow the compiler
> >    to not insert them in the first place (e.g. using
> >    <type_name>'Range when looping through an array
> >    indexed by <type_name>
>
> Kinda defeat the point of the Original Troll, don't they, though?

not really, certainly not point 2) and given that MS seem
keen to actually produce slower code with every release, I
would assume they would leave these checks in even where
efficiency needs are more demanding than safety needs. ;-)

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

[CBFalconer]

Richard Bos wrote:
> 
> Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
> 
> >    Would you be happy if the C language went back to not
> >    enforcing/type checking parameters to functions?
> 
> No. Because checking parameter passing can be done, and takes time only,
> at compile-time. Checking array bounds has an impact on the performance
> of the program itself.
> Oh, btw, there _are_ bounds-checking compilers for C. They get used
> where the extra safety is deemed important enough to justify the loss of
> speed.

elsethread (I think) I recently made a recommendation about type
definitions, which could impose strong type checking in C at the
cost of a single new reserved word (I suggested deftype, if you
want to do a google search on c.l.c).  Such a feature would go far
to removing out-of-bounds errors by insisting that an array be
indexed by a declared index type.  Everything would be done at
compile time.  Without a specific cast (error prone) assignments
to the type would have to be of the type itself.  If the type can
specify a subrange things would be even better, but that
immediately implies range-checking code, so is probably not C
compatible.

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

[Marcin 'Qrczak' Kowalczyk]

Thu, 02 Aug 2001 17:30:17 GMT, CBFalconer <cbfalconer@yahoo.com> pisze:

> elsethread (I think) I recently made a recommendation about type
> definitions, which could impose strong type checking in C at the
> cost of a single new reserved word (I suggested deftype, if you
> want to do a google search on c.l.c).  Such a feature would go far
> to removing out-of-bounds errors by insisting that an array be
> indexed by a declared index type.  Everything would be done at
> compile time.

I don't believe it would help much. Most arrays have sizes which are
not compile time constants, so using a specific type for indexing
doesn't make a difference. And arithmetic on the index type can still
overflow, so it would have to be checked instead of array access.

Haskell eliminates many range checks by
1) not using arrays but lists (this is not a great thing for efficiency
   but it is great for eliminating off-by-one errors),
2) providing functions which wrap common patterns of array usage, e.g.
   iteration over all elements or mapping each element by a function to
   a new array - implementation of these functions can skip range checks.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST�PCZA
QRCZAK

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

[Ketil Z Malde]

kaz@ashi.footprints.net (Kaz Kylheku) writes:

> Languages with checks are great, but they don't compensate for bad
> programming.  What they do is displace bad programming. Programmers
> are displaced to causing other types of errors, or maybe they are
> displaced to other programming languages entirely.

This is, to me, a very surprising statement.  (In fact, I would have
thought that if the language let you take your mind off the minute and
irrelevant details like array bounds checking, it would leave more
mind share to other areas of the program.)  Could you please cite some
references for this?  Or at least a rationale behind it?

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

[Dan Cross]

In article <tmgrs9anc69q95@corp.supernews.com>,
Mike Smith <smithmc@michaelsmithHATESSPAM.org> wrote:
>Yes, I do.  However, what I also understand is that buffer overflow problems
>are a *bug*, not a "feature", and they are a bug in the *application code*,
>not the language.  Only improperly written C code can contain buffer
>overflow problems, and there is absolutely *no* excuse for finding them in
>C++ code, because the STL can be used to eliminate them completely.

Well, the same could be said of assembly language programming, but do
we program major software systems in assembler?  And of course it's
tautological that only erroneous programs have bugs.

However, just because we can use a tool effectively doesn't mean that's
the tool to use.  I could use a chainsaw to cut my butter in the
morning when I put it on my bagel, but it's a lot safer and easier to
use a butter knife instead.  A similar analogy can be drawn with
software; just because someone can write correct C code on a large
software system doesn't mean they should.  I mean, why should they?  If
it's easier and less error-prone to use, say, Ada (or Eiffel, or ...)
why not make use of those languages instead?

One reason might be, ``well, I like C.''  Hey, that's great; I like C
too (heavens forbid! :-); it's absolutely great as a low-level systems
programming language.  But I don't like using it for application
programming, because I think it lacks a lot of useful higher-level
concepts that make application programming easier (ie, a built in first
class string type, built in ADT's, true strong typing, etc).  It's a
pain to implement those again and again, but it also makes no sense to
add them to C since other languages already have those facilities.  I
don't need or want C to have all those things, because then it becomes
less effective for systems programming.

People tend to forget that a programming language is a tool, and no
single tool is appropriate for every job (you don't put in a screw with
a hammer, do you?  You do?  Watch out for your house falling over,
then.  :-).  Programmer's in particular tend to develop an almost
religious devotion to their tools, so we end up with major software
applications written in C when they could be written much more
profitably in something like Ada (or ML, Lisp, Prolog, Eiffel, Python
or whatever).

So, in summary, an old cliche is apropos: pick the best tool for the
job.  Often, when analyzing what one is doing, one will find that C
isn't that tool.  Sometimes it is, but it depends on the context.

As specifically regards applications programming, it's been my
experience that C isn't usually the best choice.  Those who believe
that moving to other languages won't eliminate buffer overflows are
probably correct, but I submit that they would be greatly diminished,
and the empirical evidence backs me up.

	- Dan C.

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

[Aaron Denney]

On 1 Aug 2001 18:44:39 -0400, Dan Cross <cross@augusta.math.psu.edu> wrote:
> (you don't put in a screw with
> a hammer, do you?  You do?  Watch out for your house falling over,
> then.  :-).

Actually... there are some screws that are supposed to be hammered in.  The tip
is smooth like a nail, but the ridges gradually grow.  AIUI, they are a variant
of the nails with screw threads in a similar pattern.  The screws can be fairly
easily removed; the nails can't.

-- 
Aaron Denney
-><-

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

[Mike Smith]

"Dan Cross" <cross@augusta.math.psu.edu> wrote in message
news:9ka0on$me1@augusta.math.psu.edu...
> In article <tmgrs9anc69q95@corp.supernews.com>,
> Mike Smith <smithmc@michaelsmithHATESSPAM.org> wrote:
> >Yes, I do.  However, what I also understand is that buffer overflow
problems
> >are a *bug*, not a "feature", and they are a bug in the *application
code*,
> >not the language.  Only improperly written C code can contain buffer
> >overflow problems, and there is absolutely *no* excuse for finding them
in
> >C++ code, because the STL can be used to eliminate them completely.
>
> Well, the same could be said of assembly language programming, but do
> we program major software systems in assembler?  And of course it's
> tautological that only erroneous programs have bugs.


Define "major".  Is the software for automotive engine computers written in
Ada?  The embedded world is one of the most "major" categories of software
development, and I'd bet that a lot of that is in fact written in assembly.

--
Mike Smith

There are perhaps 5% of the population that simply *can't* think.
There are another 5% who *can*, and *do*.
The remaining 90% *can* think, but *don't*.
-- R. A. Heinlein

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

[Bill Godfrey]

"Mike Smith" <smithmc@michaelsmith.NOSPAMorg> writes:

> Define "major".  Is the software for automotive engine computers written in
> Ada?  The embedded world is one of the most "major" categories of software
> development, and I'd bet that a lot of that is in fact written in assembly.

IME, assembly only really gets a look in when the thing powers up and
the registers need fiddling with, and wrappers around interrupt handling.

Once the bit which has to be in assembly is dealt with, it's a quick
JSR to a C function.

Other people's experiences may vary...

Bill, likes assembly code. (gcc -S is useful.)

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

[Martin Dowie]

I don't know. But I do know that MISRA (UK Motor Industry S/W
Reliability Association) publish guidelines that indicate that
Ada should be considered in preference to using C for safety
critical systems. The report defines MISRA-C, a "safe" subset
of C.

Mike Smith <smithmc@michaelsmith.NOSPAMorg> wrote in message
news:tmhe597bt0eb23@corp.supernews.com...
[snip]

> Define "major".  Is the software for automotive engine computers written
in
> Ada?  The embedded world is one of the most "major" categories of software
> development, and I'd bet that a lot of that is in fact written in
assembly.
>
> --
> Mike Smith

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

[Tor Rustad]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message
> I don't know. But I do know that MISRA (UK Motor Industry S/W
> Reliability Association) publish guidelines that indicate that
> Ada should be considered in preference to using C for safety
> critical systems. The report defines MISRA-C, a "safe" subset
> of C.

IIRC, MISRA-C explains in some detail how to use the language correct.

As a security programmer I have multiple objectives, some of the important
ones are

1. correct program
2. robust program
3. portable program
4. fast program

For each point, the importance and difficulty varies, depending of the
project. However, to me it's really a minor problem to avoid bugs like
buffer overflow and memory leaks using C. The hard part, is to get the
program correct & robust, no matter what the input is and some times no
matter what the HW does.

Using a language with more built in safty features, would of course make
this job easier, but primary for less expierenced programmers. You cannot
simply use idiot's to program critical systems, and which language to use
isn't a simple pick. If a company's technical experts are expert C
programmers, I guess the best solution is C. Many times the technical
challenge in designing og problem solving, is greather than the programming
task, that is at lest true in security engineering.

What Microsoft has to do with robust SW, I don't know. For them,
time-to-market and fast programs look to be more important objectives than
what is usually mine. OTOH, Microsoft is doing pretty well (as a company),
they can't be completely wrong. ;-)

Buffer overflow is a real problem with many current systems, and I really
think more C programmers should use the OpenBSD strlcpy() and strlcat(),
which are simpler to use correctly than their standard library friends.

--
Tor <torust AT online DOT no>
"God does not play dice" -Albert Einstein

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

[Martin Dowie]

I could have added that, IIRC, MISRA state that MISRA-C is suitable
for up to the equivalent of UK (DefStan0055/56) SIL3 or US Do-178B
LevelB systems and not the highest level of either safety standard.

Tor Rustad <torust@online.no.spam> wrote in message
news:9Mha7.3184$e%4.96024@news3.oke.nextra.no...
> "Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message
> > I don't know. But I do know that MISRA (UK Motor Industry S/W
> > Reliability Association) publish guidelines that indicate that
> > Ada should be considered in preference to using C for safety
> > critical systems. The report defines MISRA-C, a "safe" subset
> > of C.
>
> IIRC, MISRA-C explains in some detail how to use the language correct.
[snip, some good points]

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

[Marin David Condic]

Ummmmm Actually, I've heard tell of automotive computers being programmed in
Ada. I won't swear to that because I can't cite specifics - but I can attest
to this: Aircraft jet engines have controls programmed in Ada and they work
quite well, thank you. (Take a bow, Marin!) BTW: This is more than just
military jet engines - large commercial jet engines also have Ada on board.

Why? Because if the engine control fails in an aircraft, a pilot (and maybe
passengers) are going to have a really bad day. They tend to not have a
sense of humor about it either. And they aren't going to buy the excuse that
"Any *competent* programmer..." wouldn't have let this happen.

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/


"Mike Smith" <smithmc@michaelsmith.NOSPAMorg> wrote in message
news:tmhe597bt0eb23@corp.supernews.com...
>
> Define "major".  Is the software for automotive engine computers written
in
> Ada?  The embedded world is one of the most "major" categories of software
> development, and I'd bet that a lot of that is in fact written in
assembly.
>

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

[David Gillon]

Marin David Condic wrote:
> "Mike Smith" <smithmc@michaelsmith.NOSPAMorg> wrote:
> > Define "major".  Is the software for automotive engine computers written in
> > Ada?  The embedded world is one of the most "major" categories of software
> > development, and I'd bet that a lot of that is in fact written in assembly.
> 
> Ummmmm Actually, I've heard tell of automotive computers being programmed in
> Ada. I won't swear to that because I can't cite specifics - but I can attest
> to this: Aircraft jet engines have controls programmed in Ada and they work
> quite well, thank you. (Take a bow, Marin!) 

It occurs to me I've never seen a comparison between the complexity of a
typical 
automotive engine controller and a jet engine FADEC. Anyone have any
useful data for comparison--LoC, function points, whatever?

> BTW: This is more than just
> military jet engines - large commercial jet engines also have Ada on board.

Also latest generation large commercial jets in general, the Boeing 777
being a case in point.

> Why? Because if the engine control fails in an aircraft, a pilot (and maybe
> passengers) are going to have a really bad day. They tend to not have a
> sense of humor about it either. And they aren't going to buy the excuse that
> "Any *competent* programmer..." wouldn't have let this happen.

Ditto for the flight controls and other safety critical avionics.
FAA/JAA certification requirements might come as an unpleasant shock to
a lot of developers used to working at lower safety integrity levels.

-- 

David Gillon

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

[Dan Cross]

In article <tmhe597bt0eb23@corp.supernews.com>,
Mike Smith <smithmc@michaelsmith.NOSPAMorg> wrote:
>> Well, the same could be said of assembly language programming, but do
>> we program major software systems in assembler?  And of course it's
>> tautological that only erroneous programs have bugs.
>
>Define "major".  Is the software for automotive engine computers written in
>Ada?  The embedded world is one of the most "major" categories of software
>development, and I'd bet that a lot of that is in fact written in assembly.

Actually, a significant amount of embedded systems development is done
in high-level languages (a fair amount is even done in Ada).  Sure, a lot
of things use assembler at some point (even Unix has some assembler
routines in it), but it's usually not the focal point.

	- Dan C.

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

[Mike Williams]

In article <9kbsre$8b0@augusta.math.psu.edu>,
 cross@augusta.math.psu.edu (Dan Cross) writes:

|> Actually, a significant amount of embedded systems development is done
|> in high-level languages (a fair amount is even done in Ada).  Sure, a lot
|> of things use assembler at some point (even Unix has some assembler
|> routines in it), but it's usually not the focal point.

And a not insignificant amount is done in a functional language -
Erlang (http://www.erlang.org) - at least in the telecom's
sphere. Users of languages such as C, C++, Ada etc often don't
realise that there are even higher level languages!

/m

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

[Richard Bos]

mike@erix.ericsson.se (Mike Williams) wrote:

> And a not insignificant amount is done in a functional language -
> Erlang (http://www.erlang.org) - at least in the telecom's
> sphere. Users of languages such as C, C++, Ada etc often don't
> realise that there are even higher level languages!

Don't be daft. We all know there is something called Lisp <g>.

Richard

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

[Dan Cross]

In article <9kdg7d$17g$1@news.du.uab.ericsson.se>,
Mike Williams <mike@erix.ericsson.se> wrote:
>And a not insignificant amount is done in a functional language -
>Erlang (http://www.erlang.org) - at least in the telecom's
>sphere. Users of languages such as C, C++, Ada etc often don't
>realise that there are even higher level languages!

An excellent point!  Erlang is definately a snazzy language.

	- Dan C.

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

[Dan Cross]

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.

>>Languages with checks - not needed - just code properly!
>
>  [...]
>

Hmm, I sort of read your note as, ``well, these things don't prevent
all errors, so why bother with them?''  Well, nothing prevents all
errors, but Chris Torek was spot on with his analogy with locks.  A
small lock isn't going to stop a professional thief with lock pick
tools, but does that mean we should throw away all the locks we use?

Personally, anything that allows me to do away the minutia that one has
to keep track of when programming in a language like C is a good
thing.  If I can push some of the effort in that arena onto the
language and runtime system, that's a big win.

Once again, it comes back to picking the right tool for the job.  When
I need to worry about the minutia (ie, in an operating system), C is
right there for me.  When I don't, I have other options.

	- Dan C.

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.

[Markus Mottl]

In comp.lang.functional Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> 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 number rose, because many more people (= more accidents, more traffic
= even more accidents) could afford ever faster cars and because the
percentage of professional (= skilled) drivers fell.

That says something about programming, too...

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.

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

[Marin David Condic]

If it is true that "The more possible programming related defects you need
to
consider, the more you think about your design" then it stands to reason
that we all ought to go back to programming in machine code. After all, I
can't think of a better way of increasing the number of possible programming
defects than having to worry if the zero you just wrote should have been a
one. Machine code programming ought to result in bullet-proof, perfect
software design! :-)

I'm not against someone bench-checking their code for errors - maybe
re-reading it as you tidy up the format and re-thinking your assumptions -
or even just leaning back and thinking about the design and wondering if
there is a better way. I do that all the time. (Of course there comes a time
when you need to shoot the programmers and move along into production.) But
I just don't think it is reasonable to believe that adding automated checks
for errors can be anything *but* a good thing.

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/


"Dan Cross" <cross@augusta.math.psu.edu> wrote in message
news:9kbvsr$a02@augusta.math.psu.edu...
> 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.

[Daniel Fischer]

Hi,

- followup ("Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>)

> If it is true that "The more possible programming related defects you
> need to consider, the more you think about your design" then it stands
> to reason that we all ought to go back to programming in machine code.

Like back when we were allowed to run our punch cards through the
"computer" once a day, 5 days a week? Yes, I agree, that would help.

On the other hand it would take years[1] to write "Hello, World" ,)



Daniel

[1] Adequate Hyperbole.

-- 
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 <9kc2mo$rbb$1@nh.pace.co.uk>,
Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote:
>If it is true that "The more possible programming related defects you need
>to
>consider, the more you think about your design" then it stands to reason
>that we all ought to go back to programming in machine code. After all, I
>can't think of a better way of increasing the number of possible programming
>defects than having to worry if the zero you just wrote should have been a
>one. Machine code programming ought to result in bullet-proof, perfect
>software design! :-)

Err, I think you're refering to Daniel Fischer here, not me.  Watch the
attributions, please.  :-)

I think there is a definite trend to treat more complex things with
more thought.  But, I contend that part of addressing the complexity is
to use tools that eliminate some of it, including programming
language.  Therefore, if programming in, say, Ada instead of C reduces
some of the complexity of the task, then that's a good thing.

>I'm not against someone bench-checking their code for errors - maybe
>re-reading it as you tidy up the format and re-thinking your assumptions -
>or even just leaning back and thinking about the design and wondering if
>there is a better way. I do that all the time. (Of course there comes a time
>when you need to shoot the programmers and move along into production.) But
>I just don't think it is reasonable to believe that adding automated checks
>for errors can be anything *but* a good thing.

Part of any software development process should be, IMHO, desk checking
code via formal reviews (and design, requirements, etc...).  In general,
I think we need more rigor, not less, but we also need better tools so
that we can apply that rigor to the appropriate places (design sticks out
in my mind most clearly) instead of the dull minutae of programming.

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

[CBFalconer]

"Warren W. Gay VE3WWG" wrote:
> 
... snip enumeration of petty little details handled by Ada
> 
>   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! ;-)

Not being an Ada user myself (real soon now), but based on my
reading, I think you omitted that Ada has specific provisions for
interfacing with other languages.  This means that bodies of well
tested (and documented) code can be directly reused.

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

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

[Warren W. Gay VE3WWG]

Bart.Vanhauwaert@nowhere.be wrote:
> 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)

Well, what can I say? Others consider it to be at least a two-fold
advantage:

1) They can write the code with the array bounds that directly maps to the
   algorithm in question.

2) The reader of the code can easily understand the code also, because
   the array bounds match the description of the algorithm.

And BTW, knowing the array bounds is not a problem. That is why Ada
provides convenient attributes like My_Array'First and My_Array'Last 
(PL/I did it with builtin functions like lbound(My_Array) and hbound(My_Array)
IIRC).

So, if this is minor to you, then so be it.

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

Yes, this is "minor", but it is "more convenient", which was my point.

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

Virtual functions do not address this issue. You clearly do not understand
the problem here.

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

You said it best -- "gross". ;-)  It is also "error prone", which is one
reason why Ada makes this service available.

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

The STL is not used in all contexts (it's just not practical). If you call 
pipe(2), you will not be using a vector from the STL. You'll use a naked
int[2] array. This is only one example.

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

Exactly.. you don't have it in C/C++, so you don't understand its advantages.
I don't mean to be condescending in that, just that you are used to defining
macros to do the same work. But this is something you should not have to do,
since it is error prone, and adds unnecessary "software clutter". Let the
computer do what it does best -- keep track of the implementation details. Ada
does precisely that.

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

Re: "sizeof" :

They often don't get it right the first time. Sure experienced developers
eventually learn this. But I've seen this mistake made regularly by 
people who work in C/C++ every day. What's worse, is that a developer
may code a sizeof expression that happens to work for his current 
platform X. Then when the code is ported to platform Y where the 
padding is different -- SURPRISE! Porting problem!

This problem is simply unnecessary, and one where the C/C++ compiler is
of no help.

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

Well, now you have switched to a "market presence" argument, which
I won't argue with. I was only illustrating a few points of "convenience"
that Ada provides. Others can respond to your marketing presence, if
they feel inclined.

> 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

BTW, this orignal post was not meant to be the reasons "Ada is best". The
posted comments are "these are some conveniences of Ada". If I wanted
to do a "sales job" for Ada, I would not start with these points, nor
use these alone.  There are so many better reasons for using Ada. ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Kaz Kylheku]

In article <3B6F312F.DA4E178E@home.com>, Warren W. Gay VE3WWG wrote:
>The STL is not used in all contexts (it's just not practical). If you call 
>pipe(2), you will not be using a vector from the STL. You'll use a naked
>int[2] array. This is only one example.

Note that pipe() is an entry point into a POSIX operating system. Unless
you have POSIX Ada bindings, you are going to have to use the C interface
to call this thing at some point. The same goes for whatever programming
language you are using.

In C++, you have the advantage that you can use the C bindings directly.
It takes very little additional work to make C headers useable by a C++
implementation.

So you can make some class that encapsulates pipes, based directly on
the C interface.

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

[Warren W. Gay VE3WWG]

Kaz Kylheku wrote:
> 
> In article <3B6F312F.DA4E178E@home.com>, Warren W. Gay VE3WWG wrote:
> >The STL is not used in all contexts (it's just not practical). If you call
> >pipe(2), you will not be using a vector from the STL. You'll use a naked
> >int[2] array. This is only one example.
> 
> Note that pipe() is an entry point into a POSIX operating system. Unless
> you have POSIX Ada bindings, you are going to have to use the C interface
> to call this thing at some point. The same goes for whatever programming
> language you are using.

Yes. So?

> In C++, you have the advantage that you can use the C bindings directly.
> It takes very little additional work to make C headers useable by a C++
> implementation.

This is a minor inconveniance for Ada, yes. But it is neither rocket
science, nor a difficult thing to do. I do it in my sleep ;-)

> So you can make some class that encapsulates pipes, based directly on
> the C interface.

Yes, you _can_, but how often is that done? The point I was making was there
are a _lot_ of similar circumstances, where C++ would have to deal with
this, and often the short cut is taken instead. Even when someone takes 
the trouble to encapsulate the POSIX call, this means that _this_ 
component is at least vulnerable to array bounds errors and is subject 
to testing/debugging. This is the "weakest link!" ;-)

OTOH, if you define an array of two integers in Ada, even the "binding"
has all array accesses checked, on this side of the POSIX call. Not so 
in your C++ wrapper class. I'll grant that this is a simple case, but
simple cases are best for illustration purposes. This is only one of
many that could be made.

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

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

[Francois Labreque]

[de-cloaks]

"Warren W. Gay VE3WWG" wrote:
> 
> Kaz Kylheku wrote:
> >
> > In C++, you have the advantage that you can use the C bindings directly.
> > It takes very little additional work to make C headers useable by a C++
> > implementation.
> 
> This is a minor inconveniance for Ada, yes. But it is neither rocket
> science, nor a difficult thing to do. I do it in my sleep ;-)

Mentioning rocket science in this thread does not make for a very
convincing argument!

[back to lurking]
-- 
Francois Labreque | Unfortunately, there's no such thing as a snooze
    flabreque     | button on a cat who wants breakfast.
        @         |      - Unattributed quote from rec.humor.funny
   videotron.ca

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

[Warren W. Gay VE3WWG]

Francois Labreque wrote:
> [de-cloaks]
> 
> "Warren W. Gay VE3WWG" wrote:
> >
> > Kaz Kylheku wrote:
> > >
> > > In C++, you have the advantage that you can use the C bindings directly.
> > > It takes very little additional work to make C headers useable by a C++
> > > implementation.
> >
> > This is a minor inconveniance for Ada, yes. But it is neither rocket
> > science, nor a difficult thing to do. I do it in my sleep ;-)
> 
> Mentioning rocket science in this thread does not make for a very
> convincing argument!

Sorry. Next time I'll cross post to sci.rockets ;-)

Seriously, I think you can understand that the point was simply that 
calling a C procedure from Ada95 is a simple thing to do in most cases.

The only time it gets remotely "tricky" is where a complex C structure 
is being used to pass information. Some care is needed to make certain 
that the Ada representation agrees with the C representation being used.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Kaz Kylheku]

In article <3B6F5AAB.CF3A6ECA@home.com>, Warren W. Gay VE3WWG wrote:
>Kaz Kylheku wrote:
>> 
>> In article <3B6F312F.DA4E178E@home.com>, Warren W. Gay VE3WWG wrote:
>> >The STL is not used in all contexts (it's just not practical). If you call
>> >pipe(2), you will not be using a vector from the STL. You'll use a naked
>> >int[2] array. This is only one example.
>> 
>> Note that pipe() is an entry point into a POSIX operating system. Unless
>> you have POSIX Ada bindings, you are going to have to use the C interface
>> to call this thing at some point. The same goes for whatever programming
>> language you are using.
>
>Yes. So?

It means that you can't avoid conforming to the array representation
demanded by the system interface, no matter what language you are using,
unless you have native bindings that provide some alternate interface.
(And chances are that someone wrote those bindings as glue which uses
C routines).

So it's hardly a C++ issue. Note that pipe() is not even a standard C++
function. A program which calls pipe() is not a standard C++ program.

>> In C++, you have the advantage that you can use the C bindings directly.
>> It takes very little additional work to make C headers useable by a C++
>> implementation.
>
>This is a minor inconveniance for Ada, yes. But it is neither rocket
>science, nor a difficult thing to do. I do it in my sleep ;-)

You may have to do it in your sleep if you have to do it over and
over again for each platform. 

>> So you can make some class that encapsulates pipes, based directly on
>> the C interface.
>
>Yes, you _can_, but how often is that done?

All the time.

>The point I was making was there
>are a _lot_ of similar circumstances, where C++ would have to deal with
>this, and often the short cut is taken instead. Even when someone takes 
>the trouble to encapsulate the POSIX call, this means that _this_ 
>component is at least vulnerable to array bounds errors and is subject 
>to testing/debugging. This is the "weakest link!" ;-)

Same with any language that doesn't have a native POSIX call (or X Window
call, or Win32 call, or PalmOS call, ....)

If the language implementation doesn't give you a wrapper, you have
to hack one yourself.

>OTOH, if you define an array of two integers in Ada, even the "binding"
>has all array accesses checked, on this side of the POSIX call. Not so 
>in your C++ wrapper class.

But on the other hand, the C++ wrapper class will be highly
portable. Because the type ``int'' of your C++ compiler will correspond
to type ``int'' in the pipe() interface, and the call is checked
against the actual declaration.

Your Ada wrapper could pass in a pointer to two bytes instead of
two integers. Great, so you have checking on the Ada side, but
what ensures that the cross-language-boundary hack is correct?

Does Ada even give you a type that is guaranteed to be the same
as the type int of the predominant C compiler of the same platform
as the language implementation?

How do you *portably* declare, in Ada, a record type that 
is precisely equivalent to POSIX struct termios from <termios.h>?

You ahve several problems there. The exact contents of the
structure a implementation-specific. Moreover, the way the struct
members are padded is also platform-specific.

But you said you can do this stuff in your sleep! Pleasant dreams...

In C++, there essentially is no mixed language programming going on; you
call the C interfaces directly.  This is the reason for C++'s success on
the heels of C, being able to seamlessly integrate with interfaces that
have C bindings. To get that struct termios, you just include <termios.h>
in your C++ code, and, like, there it is!

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

[Larry Kilgallen]

In article <hPKb7.26397$B37.531734@news1.rdc1.bc.home.com>, kaz@ashi.footprints.net (Kaz Kylheku) writes:

> Does Ada even give you a type that is guaranteed to be the same
> as the type int of the predominant C compiler of the same platform
> as the language implementation?

Please tell us the C type that corresponds to the type Integer of the
predominant Ada compiler on the platform.

For that matter, please list the other languages to which your C
compiler provides built-in interfacing, as Ada does for C, Fortran
and Cobol (i.e., portably).

> How do you *portably* declare, in Ada, a record type that 
> is precisely equivalent to POSIX struct termios from <termios.h>?

That is fairly impossible when porting to a system that does not have
POSIX.  I am sure we could all learn from the C technique for doing this.

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

[Ted Dennison]

In article <hPKb7.26397$B37.531734@news1.rdc1.bc.home.com>, Kaz Kylheku says...
>
>Your Ada wrapper could pass in a pointer to two bytes instead of
>two integers. Great, so you have checking on the Ada side, but
>what ensures that the cross-language-boundary hack is correct?

Most of this stuff is not a *hack*. Its in the Ada standard. The Ada standard
validation process ensures that the standards are upheld.

>Does Ada even give you a type that is guaranteed to be the same
>as the type int of the predominant C compiler of the same platform
>as the language implementation?

Yes it does: Interfaces.C.Int. It also gives you the capability of creating an
integer type that is guaranteed to be the same number of bits reguardless of the
platform, which C and C++ do not give you. 

>How do you *portably* declare, in Ada, a record type that 
>is precisely equivalent to POSIX struct termios from <termios.h>?

The version I have from cygwin just contains an include for sys/termios.h and 6
routine declarations. A portable binding to the routines would be trivial using
the types in Interfaces.C (assuming the ".h" file itself is really portable,
which with C is generally a bad assumption).

The termios struct itself (in sys/termios.h) uses unsigned shorts, chars, and
unsigned chars. All of those types are avilable for portable use in
Interfaces.C. Thus making a binding that matches this *portably* would be
trivial. It can be (and in some cases has been) generated by a translator
program.

>You ahve several problems there. The exact contents of the
>structure a implementation-specific. Moreover, the way the struct
>members are padded is also platform-specific.

The second problem is a non-issue. If you apply "pragma Convention (C, foo);" to
the declaration, its supposed to align the record the way C would align it.

However, you are right that Ada can't guard against the possiblity that termios
on another platform may not be the same struct. Ada that depends on C is indeed
not portable when the C itself isn't portable (which unfortunately is just about
always). If that's your point, I'd have to agree. That's why it pays to remove
yourself from the C as far as possible. :-)

However, if the differences in .h files don't affect the users much (which it
doesn't, if you use the routines and macros), then C-forced changes in the
innards of the Ada bindings won't affect the binding users much either (assuming
they stuck to the provided routines, which you can *force* in Ada by making the
record fields private).

Think of Ada "bindings" as just the Ada equivalent of the C .h files you're
accustomed to using for the same services. Most C compilers come with all the
system .h file "bindings", and most Ada compilers come with all the system
package "bindings". If the interface provided by C is reasonably portable, the
Ada interface will be at least as portable. If the *implementation* provided by
C is portable, the implementation provided by Ada can be made portable too. The
system services themselves will work just as well either way. System services
are machine code at this point, and won't ever know the difference. The only
real difference is that you aren't stuck using C. :-)

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

[Larry Kilgallen]

In article <yqGb7.25848$B37.497768@news1.rdc1.bc.home.com>, kaz@ashi.footprints.net (Kaz Kylheku) writes:
> In article <3B6F312F.DA4E178E@home.com>, Warren W. Gay VE3WWG wrote:
>>The STL is not used in all contexts (it's just not practical). If you call 
>>pipe(2), you will not be using a vector from the STL. You'll use a naked
>>int[2] array. This is only one example.
> 
> Note that pipe() is an entry point into a POSIX operating system. Unless
> you have POSIX Ada bindings, you are going to have to use the C interface
> to call this thing at some point. The same goes for whatever programming
> language you are using.

POSIX is not an operating system.

What makes you think I am going to call POSIX at some point ?
I have not done so as yet, after 13 years of Ada programming.
Can you tell me when this will happen ?

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

[Kaz Kylheku]

In article <wY7tyUcxTM0p@eisner.encompasserve.org>, Larry Kilgallen wrote:
>In article <yqGb7.25848$B37.497768@news1.rdc1.bc.home.com>, kaz@ashi.footprints.net (Kaz Kylheku) writes:
>> In article <3B6F312F.DA4E178E@home.com>, Warren W. Gay VE3WWG wrote:
>>>The STL is not used in all contexts (it's just not practical). If you call 
>>>pipe(2), you will not be using a vector from the STL. You'll use a naked
>>>int[2] array. This is only one example.
>> 
>> Note that pipe() is an entry point into a POSIX operating system. Unless
>> you have POSIX Ada bindings, you are going to have to use the C interface
>> to call this thing at some point. The same goes for whatever programming
>> language you are using.
>
>POSIX is not an operating system.

I didn't say it was. It's an interface.

>What makes you think I am going to call POSIX at some point ?

I didn't bring up POSIX.  The claim was made that C++ programs call 
the POSIX function, thereby using an usafe C array. So what if C++
programs don't call POSIX?

>I have not done so as yet, after 13 years of Ada programming.
>Can you tell me when this will happen ?

When you write a useful piece of software that runs on a mainstream
operating system? You set yourself up for that one! :)

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

[Ted Dennison]

In article <wY7tyUcxTM0p@eisner.encompasserve.org>, Larry Kilgallen says...
>
>> Note that pipe() is an entry point into a POSIX operating system. Unless
>> you have POSIX Ada bindings, you are going to have to use the C interface
>> to call this thing at some point. The same goes for whatever programming
>> language you are using.
>
>POSIX is not an operating system.
>
>What makes you think I am going to call POSIX at some point ?
>I have not done so as yet, after 13 years of Ada programming.
>Can you tell me when this will happen ?

There are POSIX Ada bindings, which I have used on occasion. However, they
really don't offer all that much that one can't get from standard Ada. Usually I
see them used to get directory information (one of the glaring omissions from
the Ada standard). But at best that just gets you pseudo-portability, as POSIX
itself isn't supported on many of the OS'es that support Ada. So if you are
going to write non-portable code, in most cases its easier to just "go native"
and use the OS itself.

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

Where would you put a package to get directory info? It would have to be an
annex since Ada doesn't necessarily target to systems that have directories
of any sort. And given a wide range of platforms that Ada runs on, could it
be designed to be portable? Or would it be better to have something like the
package Interfaces - only for operating systems? (Interfaces.Unix,
Interfaces.Windows, Interfaces.VMS?)

I'd like to have that in the language too, but there may be good reasons it
was left out. (Hard to specify precisely - hard to validate?) Maybe that's
another one of those "Standard Libraries" we're supposed to be building as
our contribution to "The Cause"? :-)

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:CyVb7.1733$NJ6.6570@www.newsranger.com...
>
> There are POSIX Ada bindings, which I have used on occasion. However, they
> really don't offer all that much that one can't get from standard Ada.
Usually I
> see them used to get directory information (one of the glaring omissions
from
> the Ada standard). But at best that just gets you pseudo-portability, as
POSIX
> itself isn't supported on many of the OS'es that support Ada. So if you
are
> going to write non-portable code, in most cases its easier to just "go
native"
> and use the OS itself.
>

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

[David Starner]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9kpa4f$j2n$1@nh.pace.co.uk...
> Where would you put a package to get directory info? It would have to be
an
> annex since Ada doesn't necessarily target to systems that have
directories
> of any sort. And given a wide range of platforms that Ada runs on, could
it
> be designed to be portable? Or would it be better to have something like
the
> package Interfaces - only for operating systems? (Interfaces.Unix,
> Interfaces.Windows, Interfaces.VMS?)

I think GNAT.Directory_Ops is portable to all the systems GNAT is, which
includes those three. For a basic directory operations package, you need
function Is_Directory (File : Filename) return Boolean and procedure
Directory_List (Directory : in Filename; Directory_List : Filename_List). It
seems that anything with directories is going to work with that, and it's a
usable mix. (It would work for music123, a program of mine that uses
GNAT.Directory_Ops.)

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

[Larry Kilgallen]

In article <tn0h3n541sppeb@corp.supernews.com>, "David Starner" <dstarner98@aasaa.ofe.org> writes:
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9kpa4f$j2n$1@nh.pace.co.uk...
>> Where would you put a package to get directory info? It would have to be
> an
>> annex since Ada doesn't necessarily target to systems that have
> directories
>> of any sort. And given a wide range of platforms that Ada runs on, could
> it
>> be designed to be portable? Or would it be better to have something like
> the
>> package Interfaces - only for operating systems? (Interfaces.Unix,
>> Interfaces.Windows, Interfaces.VMS?)
> 
> I think GNAT.Directory_Ops is portable to all the systems GNAT is, which
> includes those three. For a basic directory operations package, you need
> function Is_Directory (File : Filename) return Boolean and procedure
> Directory_List (Directory : in Filename; Directory_List : Filename_List). It
> seems that anything with directories is going to work with that, and it's a
> usable mix. (It would work for music123, a program of mine that uses
> GNAT.Directory_Ops.)

On VMS those two subprograms would not seem to offer control of whether
one wants all versions or just the latest version of a file.

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

[David Starner]

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:On2kQeHwm8CK@eisner.encompasserve.org...
> In article <tn0h3n541sppeb@corp.supernews.com>, "David Starner"
<dstarner98@aasaa.ofe.org> writes:
> >
> > I think GNAT.Directory_Ops is portable to all the systems GNAT is, which
> > includes those three. For a basic directory operations package, you need
> > function Is_Directory (File : Filename) return Boolean and procedure
> > Directory_List (Directory : in Filename; Directory_List :
Filename_List). It
> > seems that anything with directories is going to work with that, and
it's a
> > usable mix. (It would work for music123, a program of mine that uses
> > GNAT.Directory_Ops.)
>
> On VMS those two subprograms would not seem to offer control of whether
> one wants all versions or just the latest version of a file.

What does the directory accessing API (for C, Pascal, or any existing Ada
implementation) look like?
A Interfaces.* scheme starts to get ugly; you're almost forced to use some
sort of preprocessor or source constructor to go cross platform. Offering a
common scheme lets you not worry about differences in many cases.

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

[Marin David Condic]

Two points:

Anything GNAT.* is not going to be accepted across compilers. You may have
an equivalent Aonix.*, etc., but I doubt Aonix wants to be tied to something
GNAT-ish. It would obviously be more acceptable if it was Ada.*. Hence the
idea was being brought up that maybe there should be some kind of "Standard
Library" to do this.

While I don't think I've seen one in a *very* long time, there were
operating systems that had file systems that did not include heierarchical
directories. I'm not sure that GNAT.Directory_Ops would be suited to that.
I'm not sure that it would be necessary - after all, if you were on
Windows/Unix/VMS/OS-2/Macintosh and this works in all those places that
probably covers some massive percentage of users. No need to be portable to
*everything*. But if you want to make something "Standard" it ought to fit
most popular platforms.

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/


"David Starner" <dstarner98@aasaa.ofe.org> wrote in message
news:tn0h3n541sppeb@corp.supernews.com...
>
> I think GNAT.Directory_Ops is portable to all the systems GNAT is, which
> includes those three. For a basic directory operations package, you need
> function Is_Directory (File : Filename) return Boolean and procedure
> Directory_List (Directory : in Filename; Directory_List : Filename_List).
It
> seems that anything with directories is going to work with that, and it's
a
> usable mix. (It would work for music123, a program of mine that uses
> GNAT.Directory_Ops.)
>

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

[David Starner]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9kpnp0$o0o$1@nh.pace.co.uk...
> Anything GNAT.* is not going to be accepted across compilers. You may have
> an equivalent Aonix.*, etc., but I doubt Aonix wants to be tied to
something
> GNAT-ish. It would obviously be more acceptable if it was Ada.*. Hence the
> idea was being brought up that maybe there should be some kind of
"Standard
> Library" to do this.

I understand that any general package can't be named GNAT.*. (One solution
to this problem might be someone offering a root name, foo.*, and getting
someone to register interfaces under that name, so compiler people could add
useful small packages there and share them among compilers.) Note that the
suggested interface was not GNAT.Directory_Ops - I currently have a bug
report in the Debian BTS about that package taking strings and sliently
truncating the file name if needed to fit in the string, with it being
painful to go back and re-get a name with a larger buffer.

> While I don't think I've seen one in a *very* long time, there were
> operating systems that had file systems that did not include heierarchical
> directories. I'm not sure that GNAT.Directory_Ops would be suited to that.

In my proposed system, Is_Directory returns False on everything, and the
procedure that returns a list does the same thing it does when offered a
plain file on any system.

> I'm not sure that it would be necessary - after all, if you were on
> Windows/Unix/VMS/OS-2/Macintosh and this works in all those places that
> probably covers some massive percentage of users. No need to be portable
to
> *everything*. But if you want to make something "Standard" it ought to fit
> most popular platforms.

What's most popular? Windows/OS-2/Macintosh/VMS/Posix-like seems like a
pretty safe bet, right now at least.

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

[Bart.Vanhauwaert]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> Well, what can I say? Others consider it to be at least a two-fold
> advantage:

Let's just call it taste.

> And BTW, knowing the array bounds is not a problem. That is why Ada
> provides convenient attributes like My_Array'First and My_Array'Last 
> (PL/I did it with builtin functions like lbound(My_Array) and hbound(My_Array)
> IIRC).

And as we all know, lazy programmers will not use 'First and 'Last,
but will assume it's 0.

>> Again, minor advantage. The compiler will warn you if you make mistakes.
> Yes, this is "minor", but it is "more convenient", which was my point.

My point it is minor.

>> In C++ you just use virtual member funcs. Or template functions if
>> speed is primordial. Easier, cleaner. Comparable mechanisms exist
>> in C.
> Virtual functions do not address this issue. You clearly do not understand
> the problem here.

Well, why don't you explain the problem than? (In a modern C++ program
the only need for variants is interfacing with legacy API's btw)

>> Minor advantage. Totally ofset by the fact that serious software needs
>> internationalization anyway. If really needed, a gross #define hack
>> does the trick.
> You said it best -- "gross". ;-)  It is also "error prone", which is one
> reason why Ada makes this service available.

And you left out the beef of my argument of course : real software
needs internationalization anyway, rendering this feature totally
useless.

>> Read up on the STL. It does that and more (like sticking a transformation
>> in between, copying from stdin directly to a slice, etc...)
> The STL is not used in all contexts (it's just not practical). If you call 

The STL is practical and in use in major projects.

> pipe(2), you will not be using a vector from the STL. You'll use a naked
> int[2] array. This is only one example.

That's why the STL has special provisions to deal with legacy C-style
arrays.

Recommended reading for you : (I am sure you'll find it on amazon)

The C++ Standard Library -- A tutorial and reference
Nicolai M. Josuttis, Addison Wesley Longman

>> Again, this seems mostly syntactical sugar. I don't understand the
>> physical/logical argument. 
> Exactly.. you don't have it in C/C++, so you don't understand its advantages.
> I don't mean to be condescending in that, just that you are used to defining
> macros to do the same work. But this is something you should not have to do,

I have never felt the need to know the size of a certain struct. Why
don't you give an example where it is needed?

> since it is error prone, and adds unnecessary "software clutter". Let the
> computer do what it does best -- keep track of the implementation details. Ada
> does precisely that.

I prefer a programming style where implementation details don't matter
so that the code is portable.

> They often don't get it right the first time. Sure experienced developers
> eventually learn this. But I've seen this mistake made regularly by 
> people who work in C/C++ every day. What's worse, is that a developer
> may code a sizeof expression that happens to work for his current 
> platform X. Then when the code is ported to platform Y where the 
> padding is different -- SURPRISE! Porting problem!

I write code that runs on windows/unix for living. I just grepped through
my current project (rather small, 500k lines) there is not one single
sizeof in the code.

> BTW, this orignal post was not meant to be the reasons "Ada is best". The
> posted comments are "these are some conveniences of Ada". If I wanted
> to do a "sales job" for Ada, I would not start with these points, nor
> use these alone.  There are so many better reasons for using Ada. ;-)

Well, let's bring them to the table then! A bit of valuable discussion 
in a thread full of trolls won't hurt anybody.

cu bart

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

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

[James Rogers]

Bart.Vanhauwaert@nowhere.be wrote:
> 
> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> > And BTW, knowing the array bounds is not a problem. That is why Ada
> > provides convenient attributes like My_Array'First and My_Array'Last
> > (PL/I did it with builtin functions like lbound(My_Array) and hbound(My_Array)
> > IIRC).
> 
> And as we all know, lazy programmers will not use 'First and 'Last,
> but will assume it's 0.
> 

Nonesense. There is no reason at all for an Ada programmer to assume
an array begins at 0. In fact, most of the Ada arrays I have written or
used begin at 1. Now why would anyone start counting at 1? 

The default 'First for a string constant is 1. It is most likely that
a lazy Ada programmer will assume 1 as the starting point of all arrays.

If the array starts at 1 and the lazy programmer assumes a start at
0 the compiler or the run time will catch the problem. If the index
is a constant the compiler will catch the problem with a serious error
message. If the index is a variable the compiler may catch the problem,
or it may have to wait for the run time checks, depending upon how
the array index is defined. Either way you will find the program either
will not compile, or will abruptly terminate with an explanation of
the nature of the error. The lazy Ada programer will quickly have
his or her lazyness corrected.

> >> Minor advantage. Totally ofset by the fact that serious software needs
> >> internationalization anyway. If really needed, a gross #define hack
> >> does the trick.
> > You said it best -- "gross". ;-)  It is also "error prone", which is one
> > reason why Ada makes this service available.
> 
> And you left out the beef of my argument of course : real software
> needs internationalization anyway, rendering this feature totally
> useless.

What built-in support does C++ have for international character sets?
What is the name of the Unicode character set in C++? Without such
support internationalization is pretty difficult.

Jim Rogers
Colorado Springs, Colorado USA

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

[Lao Xiao Hai]

> Bart.Vanhauwaert@nowhere.be wrote:
> >
> > Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> > > And BTW, knowing the array bounds is not a problem. That is why Ada
> > > provides convenient attributes like My_Array'First and My_Array'Last
> > > (PL/I did it with builtin functions like lbound(My_Array) and hbound(My_Array)
> > > IIRC).
> >
> > And as we all know, lazy programmers will not use 'First and 'Last,
> > but will assume it's 0.
> >

Actually, when it comes to array processing, single- or multi-dimensional I find that
Ada runs circles around the C family of languages.    It is so easy to map the array
indices to the problem being solved instead of being forced to index everything from
zero.   Also, when passsing a slice of an array to a function, I never need to test
for
the upper and lower bound of the array.  Instead, 'First, 'Last, 'Range, and 'Length
give me everything I need to create portable code.   This is particulary useful when
designing generic templates.  My array index can be begin with a lower bound of a
negative number, handy for certain problems.  It can begin at any positive number,
including a value greater than one, also often quite handy.   Also, because Ada
enumeration types are an actual set of ordered values, I can reliably index an
array using the values of an enumeration type, without any concern for arithmetic
interventions.

Ada has true multi-dimensional arrays.  Consequently, we can have a simple two
or three- (or more) dimensional array as well as an array of an array (a la C).  I
can write algorithms that correspond directly to those found in Fortran (using a
pragma Convention) so I may have an array that is either column major or row
major, depending on the nature of the problem I need to solve.   There are so
many other examples that eclipse the capabilities of C that they are too numerous
to address here.   Suffice it to say, this is one area where C and C++ simply don't
measure up to Ada.

To be fair, a competent C++ programmer can use a smart array class instead of relying
on raw language arrays.  These correspond, loosely, to the array capabilities of Ada,
but still fall somewhat short.   In array processing, the designers of Ada got it
right
and the designers of the C family of languages never had a clue.   Ada is by no means
perfect in all respects, and some features of the C family of languages are quite
nice,
but Ada far surpasses C, C++, Java, and their close relatives when it comes to array
management.

Richard Riehle

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

[Ole-Hjalmar Kristensen]

Lao Xiao Hai <laoxhai@ix.netcom.com> writes:

> Ada has true multi-dimensional arrays.  Consequently, we can have a simple two
> or three- (or more) dimensional array as well as an array of an array (a la C).  I
> can write algorithms that correspond directly to those found in Fortran (using a
> pragma Convention) so I may have an array that is either column major or row
> major, depending on the nature of the problem I need to solve.   There are so
> many other examples that eclipse the capabilities of C that they are too numerous
> to address here.   Suffice it to say, this is one area where C and C++ simply don't
> measure up to Ada.

Minor nit: C HAS true multidimesional arrays, just the same as
Fortran.
The ONLY difference between C and Fortran arrays are that C arrays
are row order and start at 0.

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

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

[Bart.Vanhauwaert]

James Rogers <jimmaureenrogers@worldnet.att.net> wrote:
> Nonesense. There is no reason at all for an Ada programmer to assume
> an array begins at 0. In fact, most of the Ada arrays I have written or
> used begin at 1. Now why would anyone start counting at 1? 

Good question. I always count 0,1,2,..,n-1. (I guess you meant why
would anyone start counting at 0?)

> If the array starts at 1 and the lazy programmer assumes a start at
> 0 the compiler or the run time will catch the problem. If the index
> is a constant the compiler will catch the problem with a serious error
> message. If the index is a variable the compiler may catch the problem,
> or it may have to wait for the run time checks, depending upon how
> the array index is defined. Either way you will find the program either
> will not compile, or will abruptly terminate with an explanation of
> the nature of the error. The lazy Ada programer will quickly have
> his or her lazyness corrected.

While the C programmer wouldn't see this problem at all because his
arrays start at 0?

>> And you left out the beef of my argument of course : real software
>> needs internationalization anyway, rendering this feature totally
>> useless.
> What built-in support does C++ have for international character sets?
> What is the name of the Unicode character set in C++? Without such
> support internationalization is pretty difficult.

Just note you changed the settings from discussing a possible Ada
advantage to possible C++ disadvantages.

But you have a valid point. Theoretically there is no basic type
that directly maps to unicode. There is whar_t but it is only
guaranteed to be large enough to hold the largest character set
supported by the implementation's locale. So there is support for
international character sets although not specifically for
unicode. 

That being said. You assert that without that direct support
i18n is pretty difficult, which is untrue. The internationalization
support for C/C++ implementations on both Microsoft and Unix is
quite extensive. Enough tools exist to make the effort painless
_and_ nearly transparant to the programmer and the translators.
Point in case thousands of (desktop) applications fully translated
to nearly every imageable language.

As I've said before : what imperfections or design tradeoffs there 
might be in C/C++ as a language, that's largely made up with the
extensive platform support it receives.

cu bart

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

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

[Larry Kilgallen]

In article <lgcsk9.env.ln@10.0.0.2>, Bart.Vanhauwaert@nowhere.be writes:
> James Rogers <jimmaureenrogers@worldnet.att.net> wrote:
>> Nonesense. There is no reason at all for an Ada programmer to assume
>> an array begins at 0. In fact, most of the Ada arrays I have written or
>> used begin at 1. Now why would anyone start counting at 1? 
> 
> Good question. I always count 0,1,2,..,n-1. (I guess you meant why
> would anyone start counting at 0?)
> 
>> If the array starts at 1 and the lazy programmer assumes a start at
>> 0 the compiler or the run time will catch the problem. If the index
>> is a constant the compiler will catch the problem with a serious error
>> message. If the index is a variable the compiler may catch the problem,
>> or it may have to wait for the run time checks, depending upon how
>> the array index is defined. Either way you will find the program either
>> will not compile, or will abruptly terminate with an explanation of
>> the nature of the error. The lazy Ada programer will quickly have
>> his or her lazyness corrected.
> 
> While the C programmer wouldn't see this problem at all because his
> arrays start at 0?
> 
>>> And you left out the beef of my argument of course : real software
>>> needs internationalization anyway, rendering this feature totally
>>> useless.
>> What built-in support does C++ have for international character sets?
>> What is the name of the Unicode character set in C++? Without such
>> support internationalization is pretty difficult.
> 
> Just note you changed the settings from discussing a possible Ada
> advantage to possible C++ disadvantages.
> 
> But you have a valid point. Theoretically there is no basic type
> that directly maps to unicode. There is whar_t but it is only
> guaranteed to be large enough to hold the largest character set
> supported by the implementation's locale. So there is support for
> international character sets although not specifically for
> unicode. 
> 
> That being said. You assert that without that direct support
> i18n is pretty difficult, which is untrue. The internationalization
> support for C/C++ implementations on both Microsoft and Unix is
> quite extensive. Enough tools exist to make the effort painless
> _and_ nearly transparant to the programmer and the translators.
> Point in case thousands of (desktop) applications fully translated
> to nearly every imageable language.

That is OS-specific internationalization support.  Besides the two
separate systems you mention, there are other OS-specific systems
for MacOS and VMS, both of which are fairly language-neutral. But
none of this provides a multiplatform internationalization  capability,
regardless of whether you are using Ada or Csomething.

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

[Ted Dennison]

In article <lgcsk9.env.ln@10.0.0.2>, Bart.Vanhauwaert@nowhere.be says...
>As I've said before : what imperfections or design tradeoffs there 
>might be in C/C++ as a language, that's largely made up with the
>extensive platform support it receives.

That's stuff which any language that can speak C interfaces (C++, Ada, some
Javas, and assureadly others) can use just as easily though. Its hardly an
advantage for C alone.

There's no way a library (particularly a non-standard one) can be said to fix
the error-prone constructs that are in C already (which C++ mostly perpetuated).
The best it can do is give you some less error-prone alternatives, which it is
up to developers to scrupulously use (or not). You can't build a sturdy
structure on a rotten foundation.

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

[Warren W. Gay VE3WWG]

Bart.Vanhauwaert@nowhere.be wrote:
> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> > Well, what can I say? Others consider it to be at least a two-fold
> > advantage:
> 
> Let's just call it taste.

Fine.

> > And BTW, knowing the array bounds is not a problem. That is why Ada
> > provides convenient attributes like My_Array'First and My_Array'Last
> > (PL/I did it with builtin functions like lbound(My_Array) and hbound(My_Array)
> > IIRC).
> 
> And as we all know, lazy programmers will not use 'First and 'Last,
> but will assume it's 0.

You don't know Ada, nor Ada programmers very well do you? :-)  As someone
else kindly pointed out, if they were to "assume", they'd assume 1!  But
that is not likely anyway, since any Ada newby already knows about all
those convenient attributes that the compiler freely provides without error.

> >> In C++ you just use virtual member funcs. Or template functions if
> >> speed is primordial. Easier, cleaner. Comparable mechanisms exist
> >> in C.
> > Virtual functions do not address this issue. You clearly do not understand
> > the problem here.
> 
> Well, why don't you explain the problem than? (In a modern C++ program
> the only need for variants is interfacing with legacy API's btw)

Go back and read the first post. Then actually spend some time writing a
test program that actually sends different sized messages with msgsnd()
and msgrcv(). Obviously, you've never used these in any language, or you
would already know the problem. ;-)

> >> Minor advantage. Totally ofset by the fact that serious software needs
> >> internationalization anyway. If really needed, a gross #define hack
> >> does the trick.
> > You said it best -- "gross". ;-)  It is also "error prone", which is one
> > reason why Ada makes this service available.
> 
> And you left out the beef of my argument of course : real software
> needs internationalization anyway, rendering this feature totally
> useless.

Ada95 does provide facilities for internationalization. But even if the
Enum_Type'Image() facility only comes in ASCII? That doesn't prevent it
from being useful, does it? You're grasping at straws on this one ;-)

> >> Read up on the STL. It does that and more (like sticking a transformation
> >> in between, copying from stdin directly to a slice, etc...)
> > The STL is not used in all contexts (it's just not practical). If you call
> 
> The STL is practical and in use in major projects.

Read my response again. I said the "STL is not used in all contexts". I
never said that it not used in all projects as you seem to be replying
to.

In other words, in a given project, with or without the STL, there
will be arrays of one type or another, that exist naked without the
helpful bounds checking of a STL class. The pipe(2) system call was a 
simple case where this could occur. This is by no means exclusive ;-)

> > pipe(2), you will not be using a vector from the STL. You'll use a naked
> > int[2] array. This is only one example.
> 
> That's why the STL has special provisions to deal with legacy C-style
> arrays.
> 
> Recommended reading for you : (I am sure you'll find it on amazon)

I have used the STL and even have books on it, thank you. I know its
weaknesses too, and I have since repented  ;-)

> The C++ Standard Library -- A tutorial and reference
> Nicolai M. Josuttis, Addison Wesley Longman
> 
> >> Again, this seems mostly syntactical sugar. I don't understand the
> >> physical/logical argument.
> > Exactly.. you don't have it in C/C++, so you don't understand its advantages.
> > I don't mean to be condescending in that, just that you are used to defining
> > macros to do the same work. But this is something you should not have to do,
> 
> I have never felt the need to know the size of a certain struct. Why
> don't you give an example where it is needed?

What? You've never written a structure to a file? A socket? A message queue?

> > since it is error prone, and adds unnecessary "software clutter". Let the
> > computer do what it does best -- keep track of the implementation details. Ada
> > does precisely that.
> 
> I prefer a programming style where implementation details don't matter
> so that the code is portable.

Which is why it should be the compiler's job. You said it yourself. The
implementation details should not matter to you. I agree with this. But
programmers can't reliably take this responsibility. Compilers are
better at it (they don't get tired, sleepy or even grumpy.)

> > They often don't get it right the first time. Sure experienced developers
> > eventually learn this. But I've seen this mistake made regularly by
> > people who work in C/C++ every day. What's worse, is that a developer
> > may code a sizeof expression that happens to work for his current
> > platform X. Then when the code is ported to platform Y where the
> > padding is different -- SURPRISE! Porting problem!
> 
> I write code that runs on windows/unix for living. I just grepped through
> my current project (rather small, 500k lines) there is not one single
> sizeof in the code.

That kind of proof won't get very far. That's like trying to prove a
hypothesis with a limited emperical evidence. Anyone scrutinizing this
kind of response, simply has to ask "So?"

> > BTW, this orignal post was not meant to be the reasons "Ada is best". The
> > posted comments are "these are some conveniences of Ada". If I wanted
> > to do a "sales job" for Ada, I would not start with these points, nor
> > use these alone.  There are so many better reasons for using Ada. ;-)
> 
> Well, let's bring them to the table then! A bit of valuable discussion
> in a thread full of trolls won't hurt anybody.

In case you havn't noticed, there has been some other threads very active
in this regard (or at least in comp.lang.ada). I'm not going to repeat
all of that here ;-)  You can find them on your own time.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[David Bolen]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> Bart.Vanhauwaert@nowhere.be wrote:
(...)
> > I have never felt the need to know the size of a certain struct. Why
> > don't you give an example where it is needed?
> 
> What? You've never written a structure to a file? A socket? A message queue?

To piggy back on this slightly to ask a related question - I'd
normally say "no" to your question because a direct write of a
structure in any of those situations would be non-portable in most
languages/libraries I've used, except when using an official
standardized marshalling interface for such I/O, in which case the
overall structure size is generally unimportant.  Instead you'd want
to define what needs to be marshalled on a field by field basis or in
dynamic situations let introspection handle it.

Does Ada support simply performing I/O on such structures to
constructs as files, sockets or message queues in a portable way
(without explicit marshalling), such that some other Ada application
(even with a different compiler and/or platform) would receive the
structure intact?

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

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

[Warren W. Gay VE3WWG]

David Bolen wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> > Bart.Vanhauwaert@nowhere.be wrote:
> (...)
> > > I have never felt the need to know the size of a certain struct. Why
> > > don't you give an example where it is needed?
> >
> > What? You've never written a structure to a file? A socket? A message queue?
> 
> To piggy back on this slightly to ask a related question - I'd
> normally say "no" to your question because a direct write of a
> structure in any of those situations would be non-portable in most
> languages/libraries I've used, except when using an official
> standardized marshalling interface for such I/O, in which case the
> overall structure size is generally unimportant.  Instead you'd want
> to define what needs to be marshalled on a field by field basis or in
> dynamic situations let introspection handle it.

Are you suggesting that every binary file that you've ever done I/O
on, is don'e in a perfectly portable fashion? Really? I rather 
doubt it, because I've seen a lot of code in the form of Open
Sourced projects that do just that.

For example, if you were to write cpio, excluding the portable format
(-c), are you not going to write the binary header out directly?
Sure you are.  You don't have to of course, but this is different
from general experience.

EVEN IF YOU IGNORE FILEs, you don't have portability concerns when
you write to pipes, UNIX sockets (ie. local to the same host), 
call msgsnd() and msgrcv() for message queues. These do not require 
any endian issues because you're talking to processes within the 
same host. It would simply be a _waste_ to write to your  
process on the same host, in an endian neutral way (depending 
upon the endian orientation).

In all of these cases, you'll want to know what the "real"
length is. Of course, you could take the "I don't care about a
byte or two of extra waste", and depending upon the situation, 
I might agree.  I only point out, that in C/C++, that these
issues do arise in practical situations.

> Does Ada support simply performing I/O on such structures to
> constructs as files, sockets or message queues in a portable way
> (without explicit marshalling), such that some other Ada application
> (even with a different compiler and/or platform) would receive the
> structure intact?

It can, as can C++. But not out of the box. In Ada, you can 
define how the object is read or written. Ada's streams work
differently than C++'s streams, but the ideas are similar.

There is however, another "distributed systems annex?", to 
which I must confess ignorance of 
at the moment (I have not yet tried it), that does the equivalence 
of RPC (or at least I think GNAT does it this way).

Now I am not certain of this point, but it is _likely_, though 
probably not guaranteed, that XDR formats will be used for this 
(big endian format, portable etc.) But please don't quote me on
this, since this particular answer is entirely _wild_ _speculation_ 
on my part. Someone with more Ada experience can help us out on 
this point, if they are willing.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[David Bolen]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

(The end of the post does answer my question, so feel free to skip to
there to avoid some intermediate discussion :-))

> Are you suggesting that every binary file that you've ever done I/O
> on, is don'e in a perfectly portable fashion? Really? I rather 
> doubt it, because I've seen a lot of code in the form of Open
> Sourced projects that do just that.

Well, I'm not sure what "a lot of code" in open source projects
necessarily has to do with assumptions about my own code.

To answer your question, yes, that's how I do it.  Virtually all of my
development for the past decade+ has been networking and I'm rarely
involved in a homogenous environment (systems, tools, etc...), so as
it happens portability is ingrained in everything I do.

In fact, that's also why I prefer non-binary formats whenever possible
(unless pre-supplied portable or standards-compliant marshallers are
already available).  I find that the portability afforded by textual
formats is generally an easy trade-off for any efficiency loss.

But that's really an aside unrelated to the question I was asking.  I
wasn't looking to justify why you would take one approach over the
other, but just looking for information about how Ada handles
structure I/O.

> For example, if you were to write cpio, excluding the portable format
> (-c), are you not going to write the binary header out directly?
> Sure you are.  You don't have to of course, but this is different
> from general experience.

I'm not sure if you mean writing the full binary header as a structure
in one shot, or just writing binary data in the header.  I'd have less
of a problem with the latter than the former - although doing the
former does get to my question about Ada's structures, e.g.,
consistency of packing, compatibility across platforms and compilers.

In my case, when I do use binary data/headers, I ensure that I stamp
them with the endian-ness in which they were written.  This yields
best performance in the native environment, but permits portability.
This is the same approach, for example, that the bsddb library takes
for its meta data.

Note that cpio is a good example because only the oldest (declared
obsolete, albeit often still the default) formats used a binary
header.  All of the recent formats have been portable, and in fact,
often the headers are in ASCII.  And at a minimum, on reading, the
binary format has magic values in it that permits detection of
endian-ness.  It's awfully rare to have an archive format (whether it
be tar, zip, or whatever) that doesn't take portability into account.

> EVEN IF YOU IGNORE FILEs, you don't have portability concerns when
> you write to pipes, UNIX sockets (ie. local to the same host), 
> call msgsnd() and msgrcv() for message queues. These do not require 
> any endian issues because you're talking to processes within the 
> same host. It would simply be a _waste_ to write to your  
> process on the same host, in an endian neutral way (depending 
> upon the endian orientation).

This shifts to an endian focus when that was really only part of my
original question.  I may not have endian concerns with local I/O but
I could certainly have larger structure alignment concerns between two
communicating applications.

In the Ada case, would writing a structure to one of those constructs
then be readable (as a complete structure) from the other end with
code written with another Ada compiler from a different vendor?

> In all of these cases, you'll want to know what the "real"
> length is. Of course, you could take the "I don't care about a
> byte or two of extra waste", and depending upon the situation, 
> I might agree.  I only point out, that in C/C++, that these
> issues do arise in practical situations.

Yes, but the "real" length you want to know for the purpose of the I/O
is "on the wire", and not necessarily in-memory.  Of course, you might
want to know both lengths, but it's the wire length that matters for
the communication I/O.  And wire length versus memory length may not
be the same, so you don't necessarily want to base the former on a
query of the latter.

> > Does Ada support simply performing I/O on such structures to
> > constructs as files, sockets or message queues in a portable way
> > (without explicit marshalling), such that some other Ada application
> > (even with a different compiler and/or platform) would receive the
> > structure intact?
> 
> It can, as can C++. But not out of the box. In Ada, you can 
> define how the object is read or written. Ada's streams work
> differently than C++'s streams, but the ideas are similar.
> 
> There is however, another "distributed systems annex?", to 
> which I must confess ignorance of 
> at the moment (I have not yet tried it), that does the equivalence 
> of RPC (or at least I think GNAT does it this way).
> 
> Now I am not certain of this point, but it is _likely_, though 
> probably not guaranteed, that XDR formats will be used for this 
> (big endian format, portable etc.) But please don't quote me on
> this, since this particular answer is entirely _wild_ _speculation_ 
> on my part. Someone with more Ada experience can help us out on 
> this point, if they are willing.

Thanks - that's really what my question was aimed at.  While having
such an XDR (or XDR-like) definition in an Annex would bring that into
the Ada specification, it sounds like handling this with Ada is pretty
close to how its handled in other situations.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

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

[Warren W. Gay VE3WWG]

I cross posted this to comp.lang.c++ because it compares the
Ada and C++ streams approaches, that others might find useful
reading, whether they like the Ada approach or not.

David Bolen wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
...snip...
> To answer your question, yes, that's how I do it.  Virtually all of my
> development for the past decade+ has been networking and I'm rarely
> involved in a homogenous environment (systems, tools, etc...), so as
> it happens portability is ingrained in everything I do.

As it should be. However, in my experience, there is always local
I/O issues that do not require that "extra engineering". Another
simple example, might be I/O to/from a temporary file. 

> But that's really an aside unrelated to the question I was asking.  I
> wasn't looking to justify why you would take one approach over the
> other, but just looking for information about how Ada handles
> structure I/O.

The entire reason for the prior discussion was to illustrate why sizes
of things were needed (hence the I/O of structs for example). Ada let's
you precisely get at the physical or logical sizes upon demand. My point
was that in C/C++, you must exercise discretion to compute what you 
need with the sizeof operator. (eg. sizeof "ab" may not be 3 on your
platform, as a simple example).

> > For example, if you were to write cpio, excluding the portable format
> > (-c), are you not going to write the binary header out directly?
> > Sure you are.  You don't have to of course, but this is different
> > from general experience.
> 
> I'm not sure if you mean writing the full binary header as a structure
> in one shot, or just writing binary data in the header.  I'd have less
> of a problem with the latter than the former - although doing the
> former does get to my question about Ada's structures, e.g.,
> consistency of packing, compatibility across platforms and compilers.

Well, for a number of years, non -c headers could not be used on other
platforms. Try taking HPUX cpio non -c archive to SCO UNIX, and you
would be disappointed. I would still be surprised if many non -c
cpio formats will interoperate. I would never depend upon it, without
testing it in advance. However, that's perhaps the one aspect of
portability that you were not concerned with.

> > EVEN IF YOU IGNORE FILEs, you don't have portability concerns when
> > you write to pipes, UNIX sockets (ie. local to the same host),
> > call msgsnd() and msgrcv() for message queues. These do not require
> > any endian issues because you're talking to processes within the
> > same host. It would simply be a _waste_ to write to your
> > process on the same host, in an endian neutral way (depending
> > upon the endian orientation).
> 
> This shifts to an endian focus when that was really only part of my
> original question.  I may not have endian concerns with local I/O but
> I could certainly have larger structure alignment concerns between two
> communicating applications.

You misunderstood my intention. I was charged with showing where 
the I/O sizes were necessary -- that was the only point I was making. 

Ie., where you _don't_ have endian issues, like local unix sockets
and pipes, you'll just do I/O on the structs in question. You won't
data marshal all of the individual structure members.

> In the Ada case, would writing a structure to one of those constructs
> then be readable (as a complete structure) from the other end with
> code written with another Ada compiler from a different vendor?

(Without doing research on this, shamelessly:) I expect not because I
don't believe the LRM (Language Reference Manual [for Ada]) spells out
what the implementation has to use for the various data types in 
question. I believe they tend to be similar: For example a string (which
is a character array) is usually written out with the first subscript
value, and last subscript value, followed by the characters in the
array. However, the sizes of the lower and upper bounds might be 32
bits in one implementation, and say 16 bits on another. Yet another,
may make the octets vary in length according the the value. But for
more radical platforms that use 1's complement integers or something,
even the integer representation could be different. So really, the
answer is _no_, there is no portability guaranteed AFAIK for stream
IO, for communication on different platforms.

For portability..

You _can_ override the default 'Read and 'Write attributes
for a type, as well as the 'Input and 'Output attributes. If you do
this, you can spell out how they are represented to/from a stream.
In fact, you _will_ do this if you care about portable file formats
(although there are other ways this can be accomplished in Ada).

In C++ you'd simply do the same thing by writing stream methods for
the classes involved. But unfortunately, you cannot do this easily
for base types. For example :

#include <iostream.h>

ostream &operator<<(ostream &stream, int iobj) {
        char buf[32];

        snprintf(buf,sizeof buf,"[%d]",iobj); // my personal format                                
        return stream << buf;                 
}

won't work if I want to output ints in my "own way" (here I simply
wanted to emit the string form of the int to the stream for int
types). The reason it doesn't work, is because it's already defined 
for you :

streams.cc:15: ambiguous overload for `_IO_ostream_withassign & << int &'
/usr/include/g++/iostream.h:77: candidates are: class ostream & ostream::operator <<(char)
/usr/include/g++/iostream.h:78: class ostream & ostream::operator <<(unsigned char)
/usr/include/g++/iostream.h:79: class ostream & ostream::operator <<(signed char)
/usr/include/g++/iostream.h:86: class ostream & ostream::operator <<(int)
etc..

This is unfortunate, because if you wanted to automatically do endian
conversions for example, this choice has been eliminated. To write
out an int using your own custom format in C++, requires deriving 
a new stream class, something along the lines of :

#include <fstream.h>

class My_Stream : public ofstream {
};
  
My_Stream &operator<<(My_Stream &stream, int iobj) {
        char buf[32];

        snprintf(buf,sizeof buf,"%d",iobj);
        stream << "'" << buf << "'";   // Output int 'my way'
        return stream;
}
 
Ada's approach is different (for streams). Rather than create a whole
new stream class, you simply customize the data type formats for the
data types themselves. When they are put to the stream, your routines
are called for the I/O for those data types, instead of the default
ones.

The beauty of this is that you specify once the I/O formats that your
"building blocks" will use, and all records (objects) that use them
can then be input/output to the stream with no further code (in C++
you would additionally be forced to declare a My_Stream &operator <<()
method to output the class/struct's to the stream, if need be.

In Ada, records (struct) have each of the members output to the
stream automatically (unless you override). However, there are 
times when you need to override the record's
default I/O format in order to omit of certain members from I/O
etc. But the default does what you want in many cases.

Ada and C++ also part company in another way WRT streams:

Ada's typing mechanism permits you to refine types further. For 
example, in C++ if you declare two integer types:

    typedef int feet;
    typedef int meters;

then both of these are treated the same in the stream I/O. :<

In Ada however, you can:

    type Feet is new Integer;
    type Meters is new Integer;

and then define how Feet and Meters are I/O'd to/from a stream. These
I/O formats can be different, even though these are just specialized
distinctions of an Integer. This can be an advantage, depending upon
the range of an integer etc. (because a more efficient stream format
can be chosen for it).

My biggest beef with C++'s typing system is that it is distinguished
at the underlying implementation type alone. If I went to the trouble
of :

   typedef int feet;
   typedef int meters;

This gets in the way of specialized method calls that might be 
different:

  object::extend_length(feet measure);
  object::extend_length(meters measure); // these both cannot coexist

This fails because according to C++ rules, these map to a duplication
of methods, because feet and meters are considered "the same" (ie. int).
Ada, makes the distinction here, which again, makes it possible to
better map the concept to programming. C++ is too close to the 
implementation of the compiled code.

Anyway, I am digressing. ;-)

> > There is however, another "distributed systems annex?", to

Confirmed, as "Distributed Systems Annex E".

> > which I must confess ignorance of
> > at the moment (I have not yet tried it), that does the equivalence
> > of RPC (or at least I think GNAT does it this way).
> >
> > Now I am not certain of this point, but it is _likely_, though
> > probably not guaranteed, that XDR formats will be used for this
> > (big endian format, portable etc.) But please don't quote me on
> > this, since this particular answer is entirely _wild_ _speculation_
> > on my part. Someone with more Ada experience can help us out on
> > this point, if they are willing.
> 
> Thanks - that's really what my question was aimed at.  While having
> such an XDR (or XDR-like) definition in an Annex would bring that into
> the Ada specification, it sounds like handling this with Ada is pretty
> close to how its handled in other situations.

Well, XDR _might_ only be true for GNAT's implementation. I wouldn't
necessarily "expect" it to be so everywhere else.  However, where 
representation is important on a simple socket, you can use the streams
attribute overrides (see above) to specify how the data elements are
written. As shown, if you do this carefully, you can input and output
entire records (struct/class) as required. I find this much more 
convenient than the C++ approach to streams. Additionally, Ada
typechecks each stream I/O call as well:

    -- error if My_Int_32 is not Integer_32 type
    Integer_32'Write(Stream,My_Int_32);  

whereas C++ can automatically promote, or call an unintended
method instead:

    short My_Int_32;  // whoopsey, not a 32 bit integer.

    cout << My_Int_32; // This is actually sending out a short -- not detected

This of course, is easy to do with include files, #ifs and macros at
work. It's not usually this blatant, but this sort of error does happen.

Anyway, I hope you found that useful. ;-)
-- 
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:
>> Well, why don't you explain the problem than? (In a modern C++ program
>> the only need for variants is interfacing with legacy API's btw)
> Go back and read the first post. Then actually spend some time writing a
> test program that actually sends different sized messages with msgsnd()
> and msgrcv(). Obviously, you've never used these in any language, or you
> would already know the problem. ;-)

I tend to stay away from legacy API's, yes.

> Ada95 does provide facilities for internationalization. But even if the
> Enum_Type'Image() facility only comes in ASCII? That doesn't prevent it
> from being useful, does it? You're grasping at straws on this one ;-)

I am not. Point out a non-contrived use of this feature in a serious 
(hence i18n'ed) project. This shouldn't be too hard, since you seem
to insist on the usefullness of this feature, you must have used it
a lot yourself?

> Read my response again. I said the "STL is not used in all contexts". I
> never said that it not used in all projects as you seem to be replying
> to.

Indeed, I misread that part. I am sorry, English is not my native
language.

> In other words, in a given project, with or without the STL, there
> will be arrays of one type or another, that exist naked without the
> helpful bounds checking of a STL class. The pipe(2) system call was a 
> simple case where this could occur. This is by no means exclusive ;-)

That's basically the same argument as the msgrcv/msgsnd one.
Shoot some more (printf/scanf/gets/...). Yes I know about them.
I tend to stay away from them. Modern C++ platforms provide better,
safer solutions. Once again, the language is a small part of my
valuation. You are not forced to use dangerous API's.

>> I have never felt the need to know the size of a certain struct. Why
>> don't you give an example where it is needed?
> What? You've never written a structure to a file? A socket? A message queue?

Not on a serious project no. I use human readable files.

>> I write code that runs on windows/unix for living. I just grepped through
>> my current project (rather small, 500k lines) there is not one single
>> sizeof in the code.
> That kind of proof won't get very far. That's like trying to prove a
> hypothesis with a limited emperical evidence. Anyone scrutinizing this
> kind of response, simply has to ask "So?"

It is proof that it is possible to write a non-trivial project 
without sizeof. Which was exactly my point. Yes sizeof (or lack
thereof) has been abused. I am sure there are things in Ada
that one can abuse.

> In case you havn't noticed, there has been some other threads very active
> in this regard (or at least in comp.lang.ada). I'm not going to repeat
> all of that here ;-)  You can find them on your own time.

I am reading this from comp.lang.c++ (as you could've guessed)

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:
> >> Well, why don't you explain the problem than? (In a modern C++ program
> >> the only need for variants is interfacing with legacy API's btw)
> > Go back and read the first post. Then actually spend some time writing a
> > test program that actually sends different sized messages with msgsnd()
> > and msgrcv(). Obviously, you've never used these in any language, or you
> > would already know the problem. ;-)
> 
> I tend to stay away from legacy API's, yes.

OK, but you're not always given a choice in that ;-) You've managed to live
a sheltered life then.

> > Ada95 does provide facilities for internationalization. But even if the
> > Enum_Type'Image() facility only comes in ASCII? That doesn't prevent it
> > from being useful, does it? You're grasping at straws on this one ;-)
> 
> I am not. Point out a non-contrived use of this feature in a serious
> (hence i18n'ed) project. This shouldn't be too hard, since you seem
> to insist on the usefullness of this feature, you must have used it
> a lot yourself?

	type Colour is ( Red, Green, Blue );

	Background : Colour := Red;

	...
	begin
		-- Debug :
		Put_Line("Background = " & Colour'Image(Background));

One Put_Line statement using the Colour'Image() attribute allows me to
conveniently print out the value of the enumerated type in human 
readable terms. To do this in C++, you'd either choose between printing
the "integer" value of it, and going back to the include/declaration to
figure out what it was, _or_ you'd have to do:

	static char str_colours[] = { "red", "green", "blue" };
	enum { red, green, blue } colour;
	colour c = blue;

	printf("colour = %s\n",str_colours[c]);

... which only works if your enums start from zero. Otherwise, you additionally
have to map it :

	static char str_colours[] = { "red", "green", "blue" };
	enum { red=100, green=200, blue=300 } colour;
	colour c = blue;

        // the following is hopeless, and won't work :
    	printf("colour = %s\n",str_colours[c]);

before you object to that, let me add that enums are used with all
sorts of weird values -- not all of them start from zero. In fact, if
they all did, you'd have a harder time detecting runtime errors due to
mismatched use of enums. I purposely choose different starting values
for C/C++ enums for that reason.

> > In other words, in a given project, with or without the STL, there
> > will be arrays of one type or another, that exist naked without the
> > helpful bounds checking of a STL class. The pipe(2) system call was a
> > simple case where this could occur. This is by no means exclusive ;-)
> 
> That's basically the same argument as the msgrcv/msgsnd one.
> Shoot some more (printf/scanf/gets/...). Yes I know about them.
> I tend to stay away from them. Modern C++ platforms provide better,
> safer solutions. Once again, the language is a small part of my
> valuation. You are not forced to use dangerous API's.

If you are forced to write to a message queue, you will not be able
to avoid it. Modern or not, the POSIX interface will be with us a
long time. It is even present on some Windows machines (NT/2000) if
you want it.

> >> I have never felt the need to know the size of a certain struct. Why
> >> don't you give an example where it is needed?
> > What? You've never written a structure to a file? A socket? A message queue?
> 
> Not on a serious project no. I use human readable files.

Even to temp files?  You live a sheltered life.

> >> I write code that runs on windows/unix for living. I just grepped through
> >> my current project (rather small, 500k lines) there is not one single
> >> sizeof in the code.
> > That kind of proof won't get very far. That's like trying to prove a
> > hypothesis with a limited emperical evidence. Anyone scrutinizing this
> > kind of response, simply has to ask "So?"
> 
> It is proof that it is possible to write a non-trivial project
> without sizeof. Which was exactly my point. Yes sizeof (or lack
> thereof) has been abused. I am sure there are things in Ada
> that one can abuse.

I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
This is not a very good result for such a simple compiler request.

> > In case you havn't noticed, there has been some other threads very active
> > in this regard (or at least in comp.lang.ada). I'm not going to repeat
> > all of that here ;-)  You can find them on your own time.
> 
> I am reading this from comp.lang.c++ (as you could've guessed)

OK, but go to comp.lang.ada to get the rest. I'm not going to repeat it
all here. Sheesh. ;-)
-- 
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:
> One Put_Line statement using the Colour'Image() attribute allows me to
> conveniently print out the value of the enumerated type in human 
> readable terms. To do this in C++, you'd either choose between printing
> the "integer" value of it, and going back to the include/declaration to
> figure out what it was, _or_ you'd have to do:

Yes, the debug thing is indeed something i overlooked. I guess that's
because I mostly debug using a debugger which gives the alfanumeric
names if you watch an enum.

>> Not on a serious project no. I use human readable files.
> Even to temp files?  You live a sheltered life.

Probably then. We currently don't need temp files btw. That might
change.

(But if it's really a temp file, it only has to be readable by
the platform who created that file. So there is no problem
ignoring endianess, padding and other pitfalls.

> I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> This is not a very good result for such a simple compiler request.

I think you misunderstand the basic design decision that led to
this. Implementations are free to choose sizes of basic types
for example to maximize speed. That's a valid choice. And because
my code doesn't depend on the results of sizeof(...) I obviously
prefer the approach where the language implementation selects
the optimal representation without me having to worry about it.

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:
> > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> > This is not a very good result for such a simple compiler request.
> 
> I think you misunderstand the basic design decision that led to
> this. Implementations are free to choose sizes of basic types
> for example to maximize speed. That's a valid choice. And because
> my code doesn't depend on the results of sizeof(...) I obviously
> prefer the approach where the language implementation selects
> the optimal representation without me having to worry about it.

Well, as my closing remark on this thread, all I can say is that the
sizeof operator is clumsy. This is the only information about size
you can get from the C/C++ compiler.

OTOH, the Ada compiler can give you the precise size of
the object in question, or it's implementation size. This way, you 
don't have to wrap your mind around "implementation issues", which
are admitedly simple most of the time. However, it is just one more
opportunity for an error to go unnoticed until you port the code
to a new platform.

I like to do things once, and then move on. I don't like to 
maintain code I did 3 years ago. I want to move onto new projects.
So any compiler technology that helps me accomplish that, enhance's 
my general "experience", shall we say.
-- 
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]

> type Colour is ( Red, Green, Blue );
>
> Background : Colour := Red;
>
> ...
> begin
> -- Debug :
> Put_Line("Background = " & Colour'Image(Background));
>
> One Put_Line statement using the Colour'Image() attribute allows me to
> conveniently print out the value of the enumerated type in human
> readable terms. To do this in C++, you'd either choose between printing
> the "integer" value of it, and going back to the include/declaration to
> figure out what it was, _or_ you'd have to do:
>
> static char str_colours[] = { "red", "green", "blue" };
> enum { red, green, blue } colour;
> colour c = blue;
>
> printf("colour = %s\n",str_colours[c]);
>
> ... which only works if your enums start from zero. Otherwise, you
additionally
> have to map it :
>
> static char str_colours[] = { "red", "green", "blue" };
> enum { red=100, green=200, blue=300 } colour;
> colour c = blue;
>
>         // the following is hopeless, and won't work :
>     printf("colour = %s\n",str_colours[c]);
>
> before you object to that, let me add that enums are used with all
> sorts of weird values -- not all of them start from zero. In fact, if
> they all did, you'd have a harder time detecting runtime errors due to
> mismatched use of enums. I purposely choose different starting values
> for C/C++ enums for that reason.

With templates, you can evaluate this mapping at compile time,
enum A {a=12,b=38,c=95};

template<A v> const char* GetImage (void);
template<> const char* GetImage<a> (void) { return "a"; }
template<> const char* GetImage<b> (void) { return "b"; }
template<> const char* GetImage<c> (void) { return "c"; }

And with the help of the preprocessor, you might get even more terse syntax.
But you Ada programmers like it verbose, don't you ;-)

I didn't want to state that this is superior to Ada 'Image approach, which
is quite useful for quick hacks and debugging purpose, but I guess you
underevaluate the true power of C++ (especially in metaprogramming)

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

[Bertrand Augereau]

> With templates, you can evaluate this mapping at compile time,
> enum A {a=12,b=38,c=95};
>
> template<A v> const char* GetImage (void);
> template<> const char* GetImage<a> (void) { return "a"; }
> template<> const char* GetImage<b> (void) { return "b"; }
> template<> const char* GetImage<c> (void) { return "c"; }
>

Ok, sorry for the previous answer, I didn't get the fact that 'Image was
giving the string at run-time depending of the actual value of the enum.
In fact's there's no other way for implementing this pattern that a big
switch, which is way less elegant than 'Image attribute, which leaves the
task to the compiler.

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

[Larry Hazel]

Bertrand Augereau wrote:

> But you Ada programmers like it verbose, don't you ;-)
> 
Nope - readable and correct.

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

[Kaz Kylheku]

In article <9lb6h4$6e9$1@norfair.nerim.net>, Bertrand Augereau wrote:
>I didn't want to state that this is superior to Ada 'Image approach, which
>is quite useful for quick hacks and debugging purpose, but I guess you
>underevaluate the true power of C++ (especially in metaprogramming)

The metaprogramming power of C++ is quite pathetic. Templates are a weak
macro system that is compromised for the sake of compiling simplicity.
All they do is stuff arguments into an existing form to produce a
function or class. If templates could contain code which computes the
form, then they might be called powerful.

Only those call C++ powerful who have no experience with more powerful
languages.

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: 1137 bytes --]

Ok, I get your point but we are talking of C++ and Ada basically, classical
I agree that dedicated functional languages are way more expressive, but you
can do nice things at compile-time with these template mechanisms of C++,
especially with templates of templates (ie policy based classes)


"Kaz Kylheku" <kaz@ashi.footprints.net> a �crit dans le message news:
08ce7.63859$B37.1480312@news1.rdc1.bc.home.com...
> In article <9lb6h4$6e9$1@norfair.nerim.net>, Bertrand Augereau wrote:
> >I didn't want to state that this is superior to Ada 'Image approach,
which
> >is quite useful for quick hacks and debugging purpose, but I guess you
> >underevaluate the true power of C++ (especially in metaprogramming)
>
> The metaprogramming power of C++ is quite pathetic. Templates are a weak
> macro system that is compromised for the sake of compiling simplicity.
> All they do is stuff arguments into an existing form to produce a
> function or class. If templates could contain code which computes the
> form, then they might be called powerful.
>
> Only those call C++ powerful who have no experience with more powerful
> languages.

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

[Martin]

"Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
news:08ce7.63859$B37.1480312@news1.rdc1.bc.home.com...
> In article <9lb6h4$6e9$1@norfair.nerim.net>, Bertrand Augereau wrote:
> >I didn't want to state that this is superior to Ada 'Image approach,
which
> >is quite useful for quick hacks and debugging purpose, but I guess you
> >underevaluate the true power of C++ (especially in metaprogramming)
>
> The metaprogramming power of C++ is quite pathetic. Templates are a weak
> macro system that is compromised for the sake of compiling simplicity.
> All they do is stuff arguments into an existing form to produce a
> function or class. If templates could contain code which computes the
> form, then they might be called powerful.
>
> Only those call C++ powerful who have no experience with more powerful
> languages.

I am curious to know what programming languages you refer to?

Also, have you invested much time really digging into the potential
of templates? (I'm referring to the kinds of things Alexandrescu does
in his recent excellent book).

Martin

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

[Ray Blaak]

"Martin" <martinb@online.no> writes:
> > Only those call C++ powerful who have no experience with more powerful
> > languages.
> 
> I am curious to know what programming languages you refer to?

I would guess Lisp and Scheme, whose macros can do crazy things.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

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

[Warren W. Gay VE3WWG]

Bertrand Augereau wrote:
> > type Colour is ( Red, Green, Blue );
> >
> > Background : Colour := Red;
> >
> > ...
> > begin
> > -- Debug :
> > Put_Line("Background = " & Colour'Image(Background));
> >
> > One Put_Line statement using the Colour'Image() attribute allows me to
> > conveniently print out the value of the enumerated type in human
> > readable terms. To do this in C++, you'd either choose between printing
> > the "integer" value of it, and going back to the include/declaration to
> > figure out what it was, _or_ you'd have to do:
> >
> > static char str_colours[] = { "red", "green", "blue" };
> > enum { red, green, blue } colour;
> > colour c = blue;
> >
> > printf("colour = %s\n",str_colours[c]);
> >
> > ... which only works if your enums start from zero. Otherwise, you
> additionally
> > have to map it :
> >
> > static char str_colours[] = { "red", "green", "blue" };
> > enum { red=100, green=200, blue=300 } colour;
> > colour c = blue;
> >
> >         // the following is hopeless, and won't work :
> >     printf("colour = %s\n",str_colours[c]);
> >
> > before you object to that, let me add that enums are used with all
> > sorts of weird values -- not all of them start from zero. In fact, if
> > they all did, you'd have a harder time detecting runtime errors due to
> > mismatched use of enums. I purposely choose different starting values
> > for C/C++ enums for that reason.
> 
> With templates, you can evaluate this mapping at compile time,
> enum A {a=12,b=38,c=95};
> 
> template<A v> const char* GetImage (void);
> template<> const char* GetImage<a> (void) { return "a"; }
> template<> const char* GetImage<b> (void) { return "b"; }
> template<> const char* GetImage<c> (void) { return "c"; }
> 
> And with the help of the preprocessor, you might get even more terse syntax.
> But you Ada programmers like it verbose, don't you ;-)
> 
> I didn't want to state that this is superior to Ada 'Image approach, which
> is quite useful for quick hacks and debugging purpose, but I guess you
> underevaluate the true power of C++ (especially in metaprogramming)

Well, that's not bad, but compared to Ada, it still appears rather
clumsy.  Especially if you had 100++ items in the enumerated set, it 
becomes a _lot_ more clumsy ;-)  
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[David Thompson]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
...
> I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> This is not a very good result for such a simple compiler request.
>
Not true.  In any conforming implementation of either C or C++
sizeof "ab" is 3.  Perhaps you meant one of two other things:

- sizeof 'a' /* a _character_ literal, not string */ is 1 in C++,
but in C sizeof(int), which is not standardized and can vary,
although I would be very surprised to ever find it 3.

- given struct foo { char bar [3]; }, sizeof(struct foo) or
in C++ of (foo), or of any object declared with such type,
_could_ be larger than 3 if the implementation has
nontrivial alignment requirements for such a type.

--
- David.Thompson 1 now at worldnet.att.net

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

[Warren W. Gay VE3WWG]

David Thompson wrote:
> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
> ...
> > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> > This is not a very good result for such a simple compiler request.
> >
> Not true.  In any conforming implementation of either C or C++
> sizeof "ab" is 3.  Perhaps you meant one of two other things:

Maybe that's now true with the C99 standard. But it is definitely
_not true_ of _many_ existing pre-C99 compilers!

> - David.Thompson 1 now at worldnet.att.net

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

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

[Richard Bos]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote:

> David Thompson wrote:
> > Not true.  In any conforming implementation of either C or C++
> > sizeof "ab" is 3.  Perhaps you meant one of two other things:
> 
> Maybe that's now true with the C99 standard. But it is definitely
> _not true_ of _many_ existing pre-C99 compilers!

It was true before the C99 Standard, as well. Of course, sometimes
compilers will get things wrong. But you can't blame the language for
that; blame the implementation instead.

Richard

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

[Ian Wild]

"Warren W. Gay VE3WWG" wrote:
> 
> David Thompson wrote:
> > Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
> > ...
> > > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> > > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> > > This is not a very good result for such a simple compiler request.
> > >
> > Not true.  In any conforming implementation of either C or C++
> > sizeof "ab" is 3.  Perhaps you meant one of two other things:
> 
> Maybe that's now true with the C99 standard. But it is definitely
> _not true_ of _many_ existing pre-C99 compilers!

Just out of interest, can you name /any/ C compiler made
since, say, 1979, for which sizeof ("ab") isn't 3?

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

[Warren W. Gay VE3WWG]

Ian Wild wrote:
> "Warren W. Gay VE3WWG" wrote:
> > David Thompson wrote:
> > > Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
> > > ...
> > > > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> > > > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> > > > This is not a very good result for such a simple compiler request.
> > > >
> > > Not true.  In any conforming implementation of either C or C++
> > > sizeof "ab" is 3.  Perhaps you meant one of two other things:
> >
> > Maybe that's now true with the C99 standard. But it is definitely
> > _not true_ of _many_ existing pre-C99 compilers!
> 
> Just out of interest, can you name /any/ C compiler made
> since, say, 1979, for which sizeof ("ab") isn't 3?

BTW, not to start a flame war here, but the brackets in 
'sizeof ("ab")' are legal, but unnecessary 
and offensive, just like 'return (value);' is offensive ;-)

Re: sizeof "ab" returning 3 :

I have personally run into this problem over the last decade or so 
(but likely >= 1990 in this case).

I don't have access to the other platforms where I used to program C, 
but it may have been one of the following: SCO UNIX, Dec Alpha, or a
Solaris platform. I don't recall the precise details, but Solaris 
or SCO would be the most likely. I don't recall the version of Solaris,
but for SCO, it was the version prior to their "Open Server" platform.

I did check it on HPUX-10.2 and HPUX-11 this morning, and they 
they did in fact faithfully report 3. Red Hat Linux also reported 3,
so the problem may not be as widespread as it once was (or as I once
thought ;-)

But(!) I do know that I was burnt by this problem in the past, and have 
since vowed not to get burnt by this again.

Maybe I'll just summarize by adding that "your milage may vary".

As to whether it should or shouldn't do that, I really don't care. It
may be nice to blame a non-conforming compiler, but in the end, it is
your code that is likely to be adjusted ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Kaz Kylheku]

In article <3B7C0397.3AD029C6@home.com>, Warren W. Gay VE3WWG wrote:
>BTW, not to start a flame war here, but the brackets in 
>'sizeof ("ab")' are legal, but unnecessary 
>and offensive, just like 'return (value);' is offensive ;-)

The parentheses *are* mandatory when the operand is a type expression:

	sizeof (char *);

Also, the parentheses may be necessary in order to override
precedence. Here is an example where the presence of parantheses
changes the semantics:

	sizeof 3 + 4.3;    /* means   sizeof (int) + 4.3 */

	sizeof (3 + 4.3);  /* means   sizeof (double) */

The analogy to the return statement is irrelevant, because return is a
keyword which introduces a jump statement. It is not an operator. So
there is no question about the relative precedence of return and any
constituent of the expression being returned. Parentheses are *never*
necessary in a return statement.

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

[David C. Hoos]

----- Original Message -----
From: "Kaz Kylheku" <kaz@ashi.footprints.net>
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
To: <comp.lang.ada@ada.eu.org>
Sent: Thursday, August 16, 2001 12:53 PM
Subject: Re: How Ada could have prevented the Red Code distributed denial of
service attack.
<large snip>

> Parentheses are *never*
> necessary in a return statement.

Really??

What about
return sizeof 3 + 4.3;
vs.
return sizeof (3 + 4.3);

Seems to me that parentheses in a return statement are
sometimes necessary!!

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

[Warren W. Gay VE3WWG]

Kaz Kylheku wrote:
> In article <3B7C0397.3AD029C6@home.com>, Warren W. Gay VE3WWG wrote:
> >BTW, not to start a flame war here, but the brackets in
> >'sizeof ("ab")' are legal, but unnecessary
> >and offensive, just like 'return (value);' is offensive ;-)
> 
> The parentheses *are* mandatory when the operand is a type expression:
> 
>         sizeof (char *);

But in the context of the discussion(!) sizeof "ab" does _not_
require brackets. The rest is old news.

> The analogy to the return statement is irrelevant, because return is a
> keyword which introduces a jump statement. It is not an operator. So
> there is no question about the relative precedence of return and any
> constituent of the expression being returned. Parentheses are *never*
> necessary in a return statement.

Quite correct. Parenthesis are *never* required, but yet, people insist
on putting those pesky things there ;-)

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

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

[Ron Natalie]

=
> Re: sizeof "ab" returning 3 :
> 
> I have personally run into this problem over the last decade or so
> (but likely >= 1990 in this case).
> 
> I don't have access to the other platforms where I used to program C,
> but it may have been one of the following: SCO UNIX, Dec Alpha, or a
> Solaris platform.

By definition sizeof "ab" must be three.  Normal string literals
("ab") must an array of three chars 'a', 'b', and '\0'.  Sizeof
is always in terms of chars.

While you might think that native chars might be larger than 8 bits,
the relationship between a normal string literal and char is fixed,
as is the relationship of char to sizeof's return (that is sizeof (char)
is always 1).

This is one of the unfortunately mistakes in C and C++.  char has two
meanings.  In one case it is the smallest addressable unit of storage
and on the other hand it's used as a native character.  If you wanted
to make two byte native characters, you could do so (16 bit chars for
example), but you would lose the ability to allocate and manipulate
8 bit things.

As a result, any system that has a native character set bigger than
what can be stored in char, pretty much does all it's work either
in Multibyte representation or in wide chars (wchar_t's).  Unfortunately,
C and C++ doesn't support either one fully.  The std::basic_string type
can't deal with multibyte representations, where as numerous system
interfaces (arg list, file names, exception->what, ...) can't deal with
wchar's.  C/C++'s idea of internationalization is pretty hopelessly
half-assed.

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

[Warren W. Gay VE3WWG]

Ron Natalie wrote:
> > Re: sizeof "ab" returning 3 :
> >
> > I have personally run into this problem over the last decade or so
> > (but likely >= 1990 in this case).
> >
> > I don't have access to the other platforms where I used to program C,
> > but it may have been one of the following: SCO UNIX, Dec Alpha, or a
> > Solaris platform.
> 
> By definition sizeof "ab" must be three.  Normal string literals
> ("ab") must an array of three chars 'a', 'b', and '\0'.  Sizeof
> is always in terms of chars.

I have seen implementations return the "rounded" size for this. That
was my only point, and the rest is nothing new. I did not refer to
wide characters and such.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Ben Pfaff]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> Ron Natalie wrote:
> > > Re: sizeof "ab" returning 3 :
> > >
> > > I have personally run into this problem over the last decade or so
> > > (but likely >= 1990 in this case).
> > >
> > > I don't have access to the other platforms where I used to program C,
> > > but it may have been one of the following: SCO UNIX, Dec Alpha, or a
> > > Solaris platform.
> > 
> > By definition sizeof "ab" must be three.  Normal string literals
> > ("ab") must an array of three chars 'a', 'b', and '\0'.  Sizeof
> > is always in terms of chars.
> 
> I have seen implementations return the "rounded" size for this. That
> was my only point, and the rest is nothing new. I did not refer to
> wide characters and such.

You have never seen an ANSI/ISO C implementation with a "rounded"
size for this, because this would be a violation of the C
standards and thus it would not be a C implementation at all.
Maybe you've seen something "C-like" that does that, but it
wasn't C.
-- 
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield

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

[Ron Natalie]

Ben Pfaff wrote:

> >
> > I have seen implementations return the "rounded" size for this. That
> > was my only point, and the rest is nothing new. I did not refer to
> > wide characters and such.
> 
> You have never seen an ANSI/ISO C implementation with a "rounded"
> size for this, because this would be a violation of the C
> standards and thus it would not be a C implementation at all.
> Maybe you've seen something "C-like" that does that, but it
> wasn't C.

Yes, never, ever seen that.  Perhaps the confusion is that some
compilers will (and are allowed to) add padding between the
"implemenation defined place" that the string literals are stored,
but that isn't reflected in sizeof, it's lost space.

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

[Warren W. Gay VE3WWG]

Ron Natalie wrote:
> Ben Pfaff wrote:
> > >
> > > I have seen implementations return the "rounded" size for this. That
> > > was my only point, and the rest is nothing new. I did not refer to
> > > wide characters and such.
> >
> > You have never seen an ANSI/ISO C implementation with a "rounded"
> > size for this, because this would be a violation of the C
> > standards and thus it would not be a C implementation at all.
> > Maybe you've seen something "C-like" that does that, but it
> > wasn't C.
> 
> Yes, never, ever seen that.  Perhaps the confusion is that some
> compilers will (and are allowed to) add padding between the
> "implemenation defined place" that the string literals are stored,
> but that isn't reflected in sizeof, it's lost space.

Nope, not confusing it with padding. However, I'll grant that it may 
have been a "broken implementation" ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Ian Wild]

"Warren W. Gay VE3WWG" wrote:
> 
> Ron Natalie wrote:
> > Yes, never, ever seen that.  Perhaps the confusion is that some
> > compilers will (and are allowed to) add padding between the
> > "implemenation defined place" that the string literals are stored,
> > but that isn't reflected in sizeof, it's lost space.
> 
> Nope, not confusing it with padding. However, I'll grant that it may
> have been a "broken implementation" ;-)

Hmmm...

Your original claim was that "On 5 different platforms, the
sizeof "ab" could yeild the answers 3,4 or 8, depending upon
the platforms chosen".  Either you've been particularly unlucky
in your choice of compilers or your test program was at fault.
Two implementations broken in exactly the same place?  Well, maybe...

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

[Karthik Gurusamy]

On 16 Aug 2001, Ben Pfaff wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>
> > Ron Natalie wrote:
> > > > Re: sizeof "ab" returning 3 :
> > > >
> > > > I have personally run into this problem over the last decade or so
> > > > (but likely >= 1990 in this case).
> > > >
> > > > I don't have access to the other platforms where I used to program C,
> > > > but it may have been one of the following: SCO UNIX, Dec Alpha, or a
> > > > Solaris platform.
> > >
> > > By definition sizeof "ab" must be three.  Normal string literals
> > > ("ab") must an array of three chars 'a', 'b', and '\0'.  Sizeof
> > > is always in terms of chars.
> >
> > I have seen implementations return the "rounded" size for this. That
> > was my only point, and the rest is nothing new. I did not refer to
> > wide characters and such.
>
> You have never seen an ANSI/ISO C implementation with a "rounded"
> size for this, because this would be a violation of the C
> standards and thus it would not be a C implementation at all.
> Maybe you've seen something "C-like" that does that, but it
> wasn't C.

If I have
 char title[] = "hello world!";

Is sizeof title guaranteed to be 13 (strlen("hello world!) + 1)? Can it
ever happen sizeof title is more than 13?

Thanks,
Karthik

> --
> "When I have to rely on inadequacy, I prefer it to be my own."
> --Richard Heathfield
>

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

[Ben Pfaff]

Karthik Gurusamy <karthikg@cisco.com> writes:

> If I have
>  char title[] = "hello world!";
> 
> Is sizeof title guaranteed to be 13 (strlen("hello world!) +
> 1)?

Yes.

> Can it ever happen sizeof title is more than 13?

No.

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

[Kaz Kylheku]

In article <3B7BC847.61D7EF55@home.com>, Warren W. Gay VE3WWG wrote:
>David Thompson wrote:
>> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
>> ...
>> > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
>> > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
>> > This is not a very good result for such a simple compiler request.
>> >
>> Not true.  In any conforming implementation of either C or C++
>> sizeof "ab" is 3.  Perhaps you meant one of two other things:
>
>Maybe that's now true with the C99 standard. But it is definitely

sizeof "ab" == 3 is a C89 feature. I don't have a copy of K&R 1978
but I'd be surprised if it did not document this as well.

>_not true_ of _many_ existing pre-C99 compilers!

Could you name one?

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

[Samuel T. Harris]

Kaz Kylheku wrote:
> 
> In article <3B7BC847.61D7EF55@home.com>, Warren W. Gay VE3WWG wrote:
> >David Thompson wrote:
> >> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
> >> ...
> >> > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> >> > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> >> > This is not a very good result for such a simple compiler request.
> >> >
> >> Not true.  In any conforming implementation of either C or C++
> >> sizeof "ab" is 3.  Perhaps you meant one of two other things:
> >
> >Maybe that's now true with the C99 standard. But it is definitely
> 
> sizeof "ab" == 3 is a C89 feature. I don't have a copy of K&R 1978
> but I'd be surprised if it did not document this as well.
> 
> >_not true_ of _many_ existing pre-C99 compilers!
> 
> Could you name one?

I do have my 1978 K&R handy and it is indeed ambiguous
as to whether or not the zero value automatically appended
after a string constant should or should not be counted
by size_of.

The definition of size_of discusses the "size" of an object
while a string constant is defined as a sequence of chars
between quotes. A zero value which is appended after or
at the end the string by the compiler. Is is unclear as
to whether or not the zero value is considered part of the
string constant.

There is a discussion of the difference between 'x' and "x"
which stipulates that "x" uses storage for 'x' and a zero value.
Note that this reference is _not_ part of the C Reference Manual
section.

This seems to indicate that the zero value is part of the
storage of the string constant but size_of is not defined
in terms of storage, but in terms of the size of an object.

So, according to 1978 K&R, the value of size_of "ab" is
indeed open to interpretation.

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

[Michael Rubenstein]

On Thu, 16 Aug 2001 17:31:06 GMT, kaz@ashi.footprints.net (Kaz
Kylheku) wrote:

>In article <3B7BC847.61D7EF55@home.com>, Warren W. Gay VE3WWG wrote:
>>David Thompson wrote:
>>> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
>>> ...
>>> > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
>>> > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
>>> > This is not a very good result for such a simple compiler request.
>>> >
>>> Not true.  In any conforming implementation of either C or C++
>>> sizeof "ab" is 3.  Perhaps you meant one of two other things:
>>
>>Maybe that's now true with the C99 standard. But it is definitely
>
>sizeof "ab" == 3 is a C89 feature. I don't have a copy of K&R 1978
>but I'd be surprised if it did not document this as well.

Not quite.  K&R 1978 didn't require that sizeof(char) == 1
(though I've never heard of an implementation in which it was
not), so sizeof "ab" could be larger than 3.  However, it did
require that sizeof return the number of bytes, so sizeof("ab")
did have to be a multiple of 3.  From K&R 1978 7.2:

	The sizeof operator yields the size, in bytes, of its 
	operand.  (A byte is undefined by the language except in 
	terms of the value of sizeof.  However, in all existing 
	implementations a byte is the space required to hold a 
	char.)  When applied to an array, the result is the total
	number of bytes in the array.
-- 
Michael M Rubenstein

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

[Clark S. Cox III]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:

> David Thompson wrote:
> > Warren W. Gay VE3WWG <ve3wwg@home.com> wrote :
> > ...
> > > I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could
> > > yeild the answers 3,4 or 8, depending upon the platforms chosen ;-)
> > > This is not a very good result for such a simple compiler request.
> > >
> > Not true.  In any conforming implementation of either C or C++
> > sizeof "ab" is 3.  Perhaps you meant one of two other things:
> 
> Maybe that's now true with the C99 standard. But it is definitely
> _not true_ of _many_ existing pre-C99 compilers!

    No, it was true with C89/C90 as well. If your compiler gives
anything other than 3 for (sizeof "ab"), then it is broken.


-- 
Clark S. Cox III
clarkcox3@yahoo.com
http://www.whereismyhead.com/clark/

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

[Greg Comeau]

In article <3B7C1EF2.4DF3C7A5@gsde.hou.us.ray.com>,
Samuel T. Harris <samuel_t_harris@raytheon.com> wrote:
>I do have my 1978 K&R handy and it is indeed ambiguous
>as to whether or not the zero value automatically appended
>after a string constant should or should not be counted
>by size_of.

I'm surprised!  BTW, it's sizeof not size_of

>The definition of size_of

sizeof! :)

>discusses the "size" of an object

Ok.

>while a string constant is defined as a sequence of chars
>between quotes.

Ok.

>A zero value which is appended after or
>at the end the string by the compiler.

Ok.

So, taking the above 3 ok's together, something such as "ab"
contains 3 characters, 'a', 'b', and '\0'.  And size the size
of this object is 3.

>Is is unclear as
>to whether or not the zero value is considered part of the
>string constant.

Why is it unclear?  You just said above that it's appended.
How is that ambiguous?

>There is a discussion of the difference between 'x' and "x"
>which stipulates that "x" uses storage for 'x' and a zero value.

That sounds right, and does not change the above.

>Note that this reference is _not_ part of the C Reference Manual
>section.

What does it say in the C ref Manual then?

>This seems to indicate that the zero value is part of the
>storage of the string constant

Agreed.

>but size_of

sizeof!

>is not defined in terms of storage, but in terms of the size of an object.

And what do they say that maks this difference of phrasing
ambiguous as to what sizeof a string literal meant to K&R.

>So, according to 1978 K&R, the value of size_of "ab" is
>indeed open to interpretation.

It's not obvious to me how it's open to interpretation.
-- 
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries.  Have you tried it?

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

[Samuel T. Harris]

Greg Comeau wrote:
> 
> In article <3B7C1EF2.4DF3C7A5@gsde.hou.us.ray.com>,
> Samuel T. Harris <samuel_t_harris@raytheon.com> wrote:
> >I do have my 1978 K&R handy and it is indeed ambiguous
> >as to whether or not the zero value automatically appended
> >after a string constant should or should not be counted
> >by size_of.
> 
> I'm surprised!  BTW, it's sizeof not size_of
> 
> >The definition of size_of
> 
> sizeof! :)

Of course. My apologies for the mis-spelling.

> 
> >discusses the "size" of an object
> 
> Ok.
> 
> >while a string constant is defined as a sequence of chars
> >between quotes.
> 
> Ok.

Do note that the zero value is _not_ part of the sequence
of chars between the quotes.

> 
> >A zero value which is appended after or
> >at the end the string by the compiler.
> 
> Ok.

The wording does not state that the zero value
is part of the string object. That is part of the
problem.

> 
> So, taking the above 3 ok's together, something such as "ab"
> contains 3 characters, 'a', 'b', and '\0'.  And size the size
> of this object is 3.
> 
> >Is is unclear as
> >to whether or not the zero value is considered part of the
> >string constant.
> 
> Why is it unclear?  You just said above that it's appended.
> How is that ambiguous?

Because it is not stated that the extra zero value is
considered part of the object.

> 
> >There is a discussion of the difference between 'x' and "x"
> >which stipulates that "x" uses storage for 'x' and a zero value.
> 
> That sounds right, and does not change the above.

Exactly. This does not produce an requirements that
the zero value, which requires storage, is itself
considered part of the string object to which it is
attached.

> 
> >Note that this reference is _not_ part of the C Reference Manual
> >section.
> 
> What does it say in the C ref Manual then?

The C Reference Manual section does not compare
'x' with "x" at all so no joy there.

> 
> >This seems to indicate that the zero value is part of the
> >storage of the string constant
> 
> Agreed.

Of course, indication is still an inferrence.
We are not talking about what everyone knows to be
true. We are talking about what a language reference
says and how it can be interpreted.

> 
> >but size_of
> 
> sizeof!
> 
> >is not defined in terms of storage, but in terms of the size of an object.
> 
> And what do they say that maks this difference of phrasing
> ambiguous as to what sizeof a string literal meant to K&R.

It is unclear as to whether or not the zero value added
by the compiler is considered part of the string object.
Nothing says it is and an interpretation which considers
it part of the string constant is contrary to the definition
of a string constant (which is defined only in terms of
the characters inside the quotes).

Not only is the C Reference Manual in 1978 K&R ambigous
on this issue, it is contradictory.

It is unclear is sizeof is counting storage used by an
object or the logical size of an object since the storage
of an object and this logical size are never connected
in the C Reference Manual as corresponding concepts.

> 
> >So, according to 1978 K&R, the value of size_of "ab" is
> >indeed open to interpretation.
> 
> It's not obvious to me how it's open to interpretation.

The problems with interpretation could be resolved easily
with ...

1. A statement in the C Reference Manual section which
   says the added zero value is part of the string object.
   Nothing in the Manual makes this clear. Indeed, a string
   constant is defined as the sequence of characters inside
   the quotes. The text regarding the added zero value comes
   _after_ this definition and is not _part_ of this definition.

2. A precise definition of sizeof which involves storage
   concepts instead of simply saying "the number of bytes
   used by an array". If an array has padding, are these
   counted or not? If it has a dope-vector, is this counted
   as being some of the bytes used by the array?

Please note that this is not really a critique of the
valuable work of Kernighan and Ritchie. It is a recognition
that language specification has indeed come a long way
since then; travelling along a frequently bumpy road.
The ambiguities of the past lead to the more precise and
clear descriptions of today.

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

[Greg Comeau]

In article <Pine.GSO.4.33.0108161431560.15612-100000@longmorn.cisco.com>,
Karthik Gurusamy  <karthikg@cisco.com> wrote:
>If I have
> char title[] = "hello world!";
>
>Is sizeof title guaranteed to be 13 (strlen("hello world!) + 1)?

Assuming we're talking about Standard C or Standard C++
and assuming we're talking about the exact code sample above,
then that's the semantics each apply to the above.

>Can it ever happen sizeof title is more than 13?

Not according to Standard C or Standard C++.

Broken compilers, or compiler with extensions are another matter,
though that said, I haven't seen any getting this wrong.

BTW, there is no "identity" that sizeof "SomeChars"
is the same as strlen("SomeChar")+1, because it may contain
null bytes.
-- 
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries.  Have you tried it?

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

[Stefan Skoglund]

"Warren W. Gay VE3WWG" wrote:
> > 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)
You dont know about the first, last and range attributes on arrays, do
you ?
A simple example of direct support in Ada for databases:
A generic called Relation is available.

declare 
   type ProjectRel is new relation (RelName=>"PROJECT", operation=>Pi,
"Name"&"Location"); 
   -- Run an projection on a example relation out of Elmasri's DB book.
   accounts: Accounts; -- Instantiation , starts processing

   account:=accounts�first;  -- hrrm dont really works but it is the
gist of it.
begin
   accounts(account).Name 
account:=account'succ to iterate fw in the set.

'succ is defined to walk every tuple once and only once

   if ok 
     commit; 
   end if;
end; -- potentially run rollback

An easy way of iterating over every tuple which matches the query.


> > Minor advantage. Totally ofset by the fact that serious software needs
> > internationalization anyway. If really needed, a gross #define hack
> > does the trick.
> 
> You said it best -- "gross". ;-)  It is also "error prone", which is one
> reason why Ada makes this service available.

And IT really requires a good c preprocessor and well good c
preprocessors
isn't available always. Every preprocessor has some uncharted bugs.

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.

[Warren W. Gay VE3WWG]

Marin David Condic 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. 

Yes, this is _very_ cool. I change buffer sizes to provoke
different tests in code where there might be buffer size issues. All it
takes is one central change, where the array is declared. Like you've
pointed out, the entire rest of the project then adjusts as is necessary.

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

Not only that, there is a chance that when macros are used, that a macro
can be silently #undef and redefined differently. In larger projects, this
is a real possibility and it happens. People tend to re-use the same names!

> 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

To be fair, not all hard-coded references will be compile time errors (if they
currently fall within the current acceptable bounds of that array). However,
I agree that if "you hose it up", then you bear the responsibility of the
consequences. No language is going to protect you totally from poor practices.

But the compiler will point out the hard-coded reference should the array
bounds change in a later revision of the code, that makes it illegal. Also
an exception will be raised due to slicing (in a procedure/function call),
if the slice range falls outside of the hardcoded value (1 likely).
-- 
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]

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.

[Warren W. Gay VE3WWG]

Bart.Vanhauwaert@nowhere.be wrote:
> 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

Yes, but your STL classes cannot help you to deal with regular arrays. In Ada,
these attributes work on _any_ array. Not just ones cooked up by your STL
classes.

> 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

Fixed sized arrays occur all the time. When you fill out tax forms, 
medical forms, drivers license forms, are not all the spaces fixed
in length? Fixed lengths occur all the time in programmed systems
as well.

Even when "length" is not fixed, often the maximum is. I know
the point you're making, but its not justified here. For example,
pipe(2) is not going to have a problem with an array of 2 file
descriptors in an int[2] array. It's never going to return more
than 2. No need to make a conspiracy out of it ;-)
-- 
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:
>> I am not really sure where this is fundamentally different from
>> for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)
>>         ...
>> and
> Yes, but your STL classes cannot help you to deal with regular arrays. In Ada,
> these attributes work on _any_ array. Not just ones cooked up by your STL
> classes.

Doctor it hurts if I do this. Well, don't do that then! Don't use
arrays, use std::vector.

> Fixed sized arrays occur all the time. When you fill out tax forms, 
> medical forms, drivers license forms, are not all the spaces fixed
> in length? Fixed lengths occur all the time in programmed systems
> as well.

Well, I'd certainly NOT use a fixed length array for things you
are likely to find on tax forms/medical forms/... Yes, i'd check
validity at form entry (number of digits, format, etc) But
i'd store it as a free form unlimited length string.

Because it might be easy to change is array(1..12) of character
to is array (1..13) of character. An indeed if you meticously used
'Length everywhere no problem. But once you start thinking this
was it ends up in your protocols (oeps, lucky we had some
reserved(1..12) of character at the end of our message!), in
your file formats, etc.. where the real problems are.

> Even when "length" is not fixed, often the maximum is. I know
> the point you're making, but its not justified here. For example,
> pipe(2) is not going to have a problem with an array of 2 file
> descriptors in an int[2] array. It's never going to return more
> than 2. No need to make a conspiracy out of it ;-)

You know, you can still put those file descriptors in a std::vector<int>
and do

pipe(&my_vector[0]);

(Yes technically, the wording of the current C++ standard is not clear
enough, but there is a defect report that rectifies this; it works
for all current implementations of the STL already in anticipation
of this correction)

But the origin of this discussion was uses of 'Length operators and
such. If it is only viable for arrays passed to pipe(2), well...
That's little value isn't it?

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:
> >> I am not really sure where this is fundamentally different from
> >> for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)
> >>         ...
> >> and
> > Yes, but your STL classes cannot help you to deal with regular arrays. In Ada,
> > these attributes work on _any_ array. Not just ones cooked up by your STL
> > classes.
> 
> Doctor it hurts if I do this. Well, don't do that then! Don't use
> arrays, use std::vector.

I'm not going to puff into the wind any more on this. Believe what
you want to, but your experience does not agree with mind. We'll just
leave it at that.

> > Fixed sized arrays occur all the time. When you fill out tax forms,
> > medical forms, drivers license forms, are not all the spaces fixed
> > in length? Fixed lengths occur all the time in programmed systems
> > as well.
> 
> Well, I'd certainly NOT use a fixed length array for things you
> are likely to find on tax forms/medical forms/... Yes, i'd check
> validity at form entry (number of digits, format, etc) But
> i'd store it as a free form unlimited length string.

So when you do a FETCH from an relational database, into a string
column value, you're going to use a dynamic array?  What initial
size are you going to specify?  I think you already know
that fixed arrays do get used, but you just don't want to 
recognize it here.  So I'll just leave you with this last example.

> Because it might be easy to change is array(1..12) of character
> to is array (1..13) of character. An indeed if you meticously used
> 'Length everywhere no problem.

But Ada programmers are a "meticulous bunch". They have to be,
because the compiler is. Anyway, it does not require meticulous
habits to make use of extremely useful features like 'Length,
'First or 'Last. Certainly less effort than it is to use your
macros, or sizeof expressions for the same thing. ;-)

> But once you start thinking this
> was it ends up in your protocols (oeps, lucky we had some
> reserved(1..12) of character at the end of our message!), in
> your file formats, etc.. where the real problems are.

APIs and protocols often have fixed sizes in them. Sheesh, where
have you been? Have you looked at TCP/IP headers for example?

> > Even when "length" is not fixed, often the maximum is. I know
> > the point you're making, but its not justified here. For example,
> > pipe(2) is not going to have a problem with an array of 2 file
> > descriptors in an int[2] array. It's never going to return more
> > than 2. No need to make a conspiracy out of it ;-)
> 
> You know, you can still put those file descriptors in a std::vector<int>
> and do
> 
> pipe(&my_vector[0]);

OK, but will your junior programmer you just hired do that? Really?
Once again, you are relying on people to do the right thing. And in
this case, its still not clear that its the "right thing" anyway,
as you freely admit.

> (Yes technically, the wording of the current C++ standard is not clear
> enough, but there is a defect report that rectifies this; it works
> for all current implementations of the STL already in anticipation
> of this correction)

That kind of assumption will "not fly" on rockets, aircraft or space
stations. It should not be the kind of assumption that runs mutual
fund companies, banks or insurance companies either.

> But the origin of this discussion was uses of 'Length operators and
> such. If it is only viable for arrays passed to pipe(2), well...
> That's little value isn't it?

You've not been listening, obviously. One last time: In Ada there is
no reason to shy away from arrays. Additionally, as Ted Dennison has 
already pointed out in another thread, you are not stuck with rigid 
array sizes anyway. If you know that you need an array of length 
N, then just like C++, you can declare a new block with the array of 
the required length. Ada then makes sure that you use the natural
construct "the array" correctly. OTOH, C++ requires you to enlist 
the help of a library to ensure safety instead. This is where the
comparison boils down to its minimum elements.

I hope this helps, because there is not much more I can add to this ;-)
-- 
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:
> So when you do a FETCH from an relational database, into a string
> column value, you're going to use a dynamic array?  What initial

I am going to use std::string. Why not?

>> But once you start thinking this
>> was it ends up in your protocols (oeps, lucky we had some
>> reserved(1..12) of character at the end of our message!), in
>> your file formats, etc.. where the real problems are.
> APIs and protocols often have fixed sizes in them. Sheesh, where
> have you been? Have you looked at TCP/IP headers for example?

Yes. And fixed four byte IP addresses cause enough headaches already.

>> pipe(&my_vector[0]);
> OK, but will your junior programmer you just hired do that? Really?

He probably will, but he will also probably not know that is
a potentially unspecified thing :)

Will your junior programmer you just hired program Ada? Really?

>> (Yes technically, the wording of the current C++ standard is not clear
>> enough, but there is a defect report that rectifies this; it works
>> for all current implementations of the STL already in anticipation
>> of this correction)
> That kind of assumption will "not fly" on rockets, aircraft or space
> stations. It should not be the kind of assumption that runs mutual
> fund companies, banks or insurance companies either.

Yes it's a defect in the C++ standard. It got caught and it will
be corrected in the next iteration. (There is nothing dishonest
about multiple iterations of a standard is there?)

> You've not been listening, obviously. One last time: In Ada there is
> no reason to shy away from arrays. Additionally, as Ted Dennison has 

In C++ there is, but it is not a problem because you can use other
equivalent structures, some provided by the STL.

Look : you are coming from an Ada background where arrays are
augmented up to a point where they became a generic object. But
only with different syntax on calling the operators than on
a real object. I think that is an inconsitency and shows the
time of the signes of early 80'ies when objects where not yet
as deeply entranched in peoples mind. At that time a 'better,
safer, array' was the best one could think of.

In C++ you use a real generic object to represent an array.
Same syntax as all other generic objects. You can write array like
objects yourself but with different semantics if you really must.
(Like, YES, a typesafe fixed size array with bounds checking and
everything mentioned in this thread). 

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:
> > So when you do a FETCH from an relational database, into a string
> > column value, you're going to use a dynamic array?  What initial
> 
> I am going to use std::string. Why not?

Well ESQL/C (Embedded SQL/C) for example will not give it to you
in that format. Though, you _could_ use the API _functions_
for relational databases, but this is always a lot more tedious.

I think most of them will also support C++ APIs now, but I don't 
know of any off of the top of my head, that will load a column 
value into std::string yet.

There was another poster, speaking of Microsoft CString (I think),
noting that it does not check array bounds. Hopefully the STL
is better in this regard, but it pays to check your assumptions
on a given platform (a given implementation may not check these
bounds -- unless perhaps if the standard dictates that it should).

> >> But once you start thinking this
> >> was it ends up in your protocols (oeps, lucky we had some
> >> reserved(1..12) of character at the end of our message!), in
> >> your file formats, etc.. where the real problems are.
> > APIs and protocols often have fixed sizes in them. Sheesh, where
> > have you been? Have you looked at TCP/IP headers for example?
> 
> Yes. And fixed four byte IP addresses cause enough headaches already.

I hope you don't think that IPv6 is going to be any different in 
this regard. It will be fixed in size as well. 

> >> pipe(&my_vector[0]);
> > OK, but will your junior programmer you just hired do that? Really?
> 
> He probably will, but he will also probably not know that is
> a potentially unspecified thing :)

I don't understand your "potentially unspecified thing" remark, but
what I have noticed is that people that are struggling with any new
language end up using very basic features, until it starts to become
2nd nature to them. You can bet they will probably use C type arrays
at the start, because it is a simpler thing to start with and to know.
After all, this is what they'll have learned first.

Arrays are much simpler for the junior to remember 
than all the baggage that comes in any class library.

> Will your junior programmer you just hired program Ada? Really?

Very likely, because 'First, 'Last and 'Length are part of the language
and _very_ easy to use and remember. Just like C/C++ arrays, the
students of the Ada language will always learn about these when
arrays are taught. The "for" loop is always taught in conjunction
with the array'Range (just short for array'First..array'Last),
so it's not a topic that would be missed, or forgotten.

> >> (Yes technically, the wording of the current C++ standard is not clear
> >> enough, but there is a defect report that rectifies this; it works
> >> for all current implementations of the STL already in anticipation
> >> of this correction)
> > That kind of assumption will "not fly" on rockets, aircraft or space
> > stations. It should not be the kind of assumption that runs mutual
> > fund companies, banks or insurance companies either.
> 
> Yes it's a defect in the C++ standard. It got caught and it will
> be corrected in the next iteration. (There is nothing dishonest
> about multiple iterations of a standard is there?)

I'm not criticising a need to revise or even fix standards or 
languages. I'm just focused on the difference between "safe
and correct" use of arrays in this thread.

> > You've not been listening, obviously. One last time: In Ada there is
> > no reason to shy away from arrays. Additionally, as Ted Dennison has
> 
> In C++ there is, but it is not a problem because you can use other
> equivalent structures, some provided by the STL.
> 
> Look : you are coming from an Ada background where arrays are
> augmented up to a point where they became a generic object. 

Whoa! Be careful about your assumptions. I've built my career
on C/C++, so don't assume that I come from an Ada background.
I have just been enlightened with some Ada background -- that
is the difference here.

To address the 2nd issue here, yes, Ada lets you add primitives
(methods) to scalars. So in this sense, yes Ada permits you
to treat simple types like objects, and this does extend to
arrays (although you cannot add new array semantics without
wrapping it into an object (class). But extending scalars
is a _feature_. ;-)

For you to add functionality to an int or a double, requires
you to wrap it into a class. The Ada compiler does not require
this type of fuss, because conceptually at the end of the day,
the implementation of a wrapper class for int is no different than
just allowing the user to "extend the type" directly in Ada.
It's just neater, safer and more conveniant in Ada.

> But
> only with different syntax on calling the operators than on
> a real object. 

You keep side-stepping the issue, which is:

  Ada has safety built into the language.
  C++ does not, and users must rely on a library to get safety, 
      from a library like the STL.

Even Ada's unofficial Booch Components library (similar to STL)
is safer, because the language's inherent safety is also applied
to these library components. 

The criticism many have of the Booch Components, which might 
be fair, is that it is more difficult for beginners to 
instantiate for use. But once the user gets past
the instantiation of the packages (ie. understands it), 
the components are no more difficult to use than the STL.

> I think that is an inconsitency and shows the
> time of the signes of early 80'ies when objects where not yet
> as deeply entranched in peoples mind. At that time a 'better,
> safer, array' was the best one could think of.

Arrays are a perfectly natural element of _all_ programming
languages, even your spiffy new functional languages will
support them. The only difference is that many languages are
more safety concious in their use, than C/C++ applies. But
C/C++ are by no means the only renegades, because FORTRAN
for example was remiss in this area (though they may have
changed their stripe in more recent times).

> In C++ you use a real generic object to represent an array.

You can in Ada also btw, but it is not necessary.

> Same syntax as all other generic objects. You can write array like
> objects yourself but with different semantics if you really must.

Again, if you need special array semantics, this can be done in
Ada. But we were not talking about special semantics, only the
ususally abused ones ;-)

> (Like, YES, a typesafe fixed size array with bounds checking and
> everything mentioned in this thread).

But you have to run to your STL to do this. That is the _point_
I keep trying to impress upon you.

The C++ STL is a fine piece of work, representing years of research
and effort. I use it myself, when in C++. But don't lose track 
of the real issue here:

In terms of _languages_, C++ is lacking in safety features. Ada
has the strongest practical safety that I have been able to find.
That is the only point of this particular thread.

Just be aware of "your limitations", as one famous actor 
used to say ;-)
-- 
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:
> I think most of them will also support C++ APIs now, but I don't 
> know of any off of the top of my head, that will load a column 
> value into std::string yet.

That is not a problem because there is a conversion operator for
c-str to std::string.

>> >> pipe(&my_vector[0]);
>> > OK, but will your junior programmer you just hired do that? Really?
>> He probably will, but he will also probably not know that is
>> a potentially unspecified thing :)
> I don't understand your "potentially unspecified thing" remark, but

Formally the standard does not specify that the above has too work.
It's defect in the standard because the intent is/was that it should
work. Thus a conforming implementation can be written for which the
above leads to undefinied behaviour (read crashed).

> what I have noticed is that people that are struggling with any new
> language end up using very basic features, until it starts to become
> 2nd nature to them. You can bet they will probably use C type arrays
> at the start, because it is a simpler thing to start with and to know.
> After all, this is what they'll have learned first.

That's because they take a bad approach to learning C++. Stroustroup
and other eminent C++ writers have warned about this kind of thing.
Well written books like 'Accelerated C++' will teach you the STL
first.

>> Will your junior programmer you just hired program Ada? Really?
> Very likely, because 'First, 'Last and 'Length are part of the language

You live in a different world. A junior programmer does generally
not know anything about Ada.

>> Look : you are coming from an Ada background where arrays are
>> augmented up to a point where they became a generic object. 
> Whoa! Be careful about your assumptions. I've built my career
> on C/C++, so don't assume that I come from an Ada background.

It strikes me as odd that given you have build a career on C/C++
that you manage to make so many basic mistakes, don't know
even the basic facts about std::string (see above) and admit
never have seen a very, very basic construct with std::vector
earlier in this thread. No way you have done serious work
in C++ (C maybe, but we all know these are very different
languages)

>> But
>> only with different syntax on calling the operators than on
>> a real object. 
> You keep side-stepping the issue, which is:
>   Ada has safety built into the language.
>   C++ does not, and users must rely on a library to get safety, 
>       from a library like the STL.

Yes. But you have not yet proven that one is better than the other.

>> In C++ you use a real generic object to represent an array.
> You can in Ada also btw, but it is not necessary.

I know, I understand generics where kind of born in Ada.

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:
> >> Will your junior programmer you just hired program Ada? Really?
> > Very likely, because 'First, 'Last and 'Length are part of the language
> 
> You live in a different world. A junior programmer does generally
> not know anything about Ada.

It is apparently becoming increasingly popular at Universities. I am
not inventing this-- there are refs to this on the net. Even head hunters
in Ontario are aware of this, and we're not a US defence type of "area".
In fact, even Ada jobs are becoming more prevalent (but still a
small segment).

> >> Look : you are coming from an Ada background where arrays are
> >> augmented up to a point where they became a generic object.
> > Whoa! Be careful about your assumptions. I've built my career
> > on C/C++, so don't assume that I come from an Ada background.
> 
> It strikes me as odd that given you have build a career on C/C++
> that you manage to make so many basic mistakes, don't know
> even the basic facts about std::string (see above) and admit
> never have seen a very, very basic construct with std::vector
> earlier in this thread. No way you have done serious work
> in C++ (C maybe, but we all know these are very different
> languages)

First let me formally address your remark from another post :

>> It is true that unless they did something wacky like make it virtual, the
>> C++ inline ++ operator is usually cheap.
>
>Look, you obviously don't know C++ that well, so please refrain from
>going into details and trying to pin C++ as a potentially
>non-optimizeable language on your assumptions which are FALSE.
>There is no question of virtual dispatch in this case as any
>junior C++ programmer will be able to tell you.

You chose to apply my response to an issue that _you_ have
assumed, because it was a personal advantage to you. You
then chose to go beyond that and make what I consider rather
unfriendly remarks. Call me human, but it put me "off". If
I had responded to the remarks at the time, I would have put
you and others _off_. I can now look at it from a distance ;-)

My response was to a more "general case",
since Ted was discussing operator ++() as it is treated in
C++, although admittedly in the loose context of the STL.
Perhaps I should have made that clearer, but I think your
response was unfair and rather unkind.

Finally, I won't get into a "what you know vs what 
I know" kind of debate. This would be counter-productive by
anyone's standards. Nobody cares either.

There may be no question of no "virtual dispatch" in a
specific instance of a STL library component. You may have
assumed a vector class (or some other), but I was speaking 
in C++ general terms about the efficiency of operator ++(). 
Again, addressing Ted's remarks.

So if you reconsider the general case, then yes, you will 
have to admit that of course you can have a virtual 
operator ++() if you should have a reason for it (I can't
imagine one, but when you talk about languages
and features, you don't always care about practical uses).

As for knowledge of the STL:

I'll freely admit that I am no expert on the STL. While you
may have the priviledge to work with STL on your projects, some
of us are still maintaining older projects, with older products.
Hence you can then understand why I don't consider C++ to be
directly liked with the STL (and another reason for it follows).

I have used the STL in the Linux/FreeBSD context, though not
extensively. Part of the reason is the GNU version of it is
not complete nor stable (in terms of changes). I don't like
developing software on a changing "platform". I do expect that
the GNU version of the STL will mature with time, and I look
forward to it (though I'll likely stick with Ada for most of my
Open Sourced work).

I have since been converted to Ada, and so I see even less
reason to go back to the STL, except where my employer may
permit me to use it (ie. making it available, and barring any 
use of Ada).

For my own development, I personally feel that Ada not only 
gives me a superior result and saves me time, it also naturally
encourages better design and modularity. Well goody for me,
I know.

So I hope this helps your understanding ;-)  (emphasis on smiley)

> >> But
> >> only with different syntax on calling the operators than on
> >> a real object.
> > You keep side-stepping the issue, which is:
> >   Ada has safety built into the language.
> >   C++ does not, and users must rely on a library to get safety,
> >       from a library like the STL.
> 
> Yes. But you have not yet proven that one is better than the other.

Well, I may have not done a "convincing" job, but I would think that
it would be somewhat self evident (not necessarily a "proof"). For me
to take Ada seriously, did not take "proof". It only took a reasonable
assurance. The "proof" is coming out in the subsequent experience (I
don't believe there is any real substitute for experience).

If I may summarize with an analogy it would be thusly :

C++ requires you to wear a leather jacket and a helmet (STL) to 
drive your the car.

I am suggesting that neither is necessary in Ada, and hence it 
is much more comfortable to drive a car without a leather 
jacket and helmet. (Safety is already inherent in the language).

Both may tend to the same result, but one is clearly more 
comfortable than the other. A comfortable driver probably encourages
better results, if I extend the analogy further.

Anyway, you'll no doubt discount the analogy as flawed, and so be 
it if you must.

I am just honestly trying to get you (and hopefully others) to 
give honest consideration to the differences and advantages that
may exist in Ada. If after you truly investigate it, and you still 
disagree, then I won't lose any sleep over it. Hopefully however,
you will be a little better informed by the process.

Most people tend to just stay with what they know however, and it 
sometimes takes a little push to get folks to look at something 
new or improved. Especially when marketing says C++ > Ada95.
But Ada95 is definitely in the well _improved_ category, 
since much experience was gained from the original Ada83 language.

[I'm going back to lurking, since my vacation is ending]  :<

For your own benefit (not mine), I hope that you someday take the
time to find out for yourself about Ada95 -- first hand.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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.

[Clark S. Cox III]

[distribution fixed]
Ted Dennison <dennison@telepath.com> wrote:

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

    Umm... Are you saying that you've never seen anything about the STL?
If so, then you are hardly in a position to critique C++.

> There are some differences, though:
> 
> o  In the Ada version, "i" would not be assignable within the loop.

    What happens when you want to skip over an element of the vector?
delete an item from the vector?

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

    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
worth it's salt would only use a single machine instruction (unless, of
course such an instruction doesn't exist on a platform, in which case
Ada couldn't do it either).

>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 is no different from what a decent C++ compiler would do.


-- 
Clark S. Cox III
clarkcox3@yahoo.com
http://www.whereismyhead.com/clark/

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

[Ted Dennison]

In article <1exve0j.1lboe8gneysd0N%clarkcox3@yahoo.com>, Clark S. Cox III
says...
>
>    What happens when you want to skip over an element of the vector?
>delete an item from the vector?

You do it some other way than modifying the loop control variable, or you use a
different kind of loop structure where the lcv *can* be modified. The option is
still there, its just that the standard "for" is something safer and easier to
optimize. :-)

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

>worth it's salt would only use a single machine instruction (unless, of

Well, that's easy to *say*. But if your compiler can't inline dispatching calls,
and "++" is a dispatching call, then it won't get inlined, and you will have
procedure call overhead for every increment. This isn't an issue at all for Ada
"for" loops, because the incrementing is *implicit*. Well...to be truthful,
you'd have the same issue with Ada if you used some abstract tagged private type
in a "while" loop instead, which would be a direct translation of what you've
done in C++. But in Ada you don't need to do that just to get type safety. The
base types already have it (if you don't disable it).


>>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 is no different from what a decent C++ compiler would do.

Quite true. The difference is that its much *easier* for an Ada compiler to do
this, becuse far more of the nessecary information is available to the optimizer
at compile time. For instance, its tough to fully unroll a loop, if you don't
know until runtime how many iterations it is going to have. In your C example,
there's no easy way the compiler could figure that out, as it is determined by
whether you modify "i" anywhere else in the body of the loop (including
potentially within called subprograms via an alias), and by the implementation
of that library "++" routine (which you could have even overridden, for all it
knows). None of this is an issue for an Ada compiler, because "i" *can't* be
(legally) modified at all.

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

[Clark S. Cox III]

Ted Dennison <dennison@telepath.com> wrote:

> Clark S. Cox III says...
> >
> >    What happens when you want to skip over an element of the vector?
> >delete an item from the vector?
> 
> You do it some other way than modifying the loop control variable, or you
> use a different kind of loop structure where the lcv *can* be modified.
> The option is still there, its just that the standard "for" is something
> safer and easier to optimize. :-)
> 
> >    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?

    However, it is unlikely that any of the STL would be implemented as
virtual functions (dynamic-dispatching as you call it). The STL are not
abstract in any way, and have no need for virtual functions.


> >worth it's salt would only use a single machine instruction (unless, of
> 
> Well, that's easy to *say*. 

    And, it's appearantly easy to *do* as most compilers do.

> But if your compiler can't inline dispatching calls, and "++" is a
> dispatching call,

    See above. Since the STL is defined completely in the header files
(it must be, since it is made up of templates), *any* code from the STL
could theoretically be inlined.

> then it won't get inlined, and you will have procedure call overhead for
> every increment. This isn't an issue at all for Ada "for" loops, because
> the incrementing is *implicit*. Well...to be truthful, you'd have the same
> issue with Ada if you used some abstract tagged private type in a "while"
> loop instead, which would be a direct translation of what you've done in
> C++.

    No, it wouldn't, because there is nothing "abstract" about the STL
classes.

> But in Ada you don't need to do that just to get type safety. The
> base types already have it (if you don't disable it).
> 
> 
> > >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 is no different from what a decent C++ compiler would do.
> 
> Quite true. The difference is that its much *easier* for an Ada compiler
> to do this, becuse far more of the nessecary information is available to
> the optimizer at compile time. For instance, its tough to fully unroll a
> loop, if you don't know until runtime how many iterations it is going to
> have. In your C example,

<nitpick>
    It was a C++ example. There is a difference (and in this case, a
*huge* difference)
</nitpick>

> there's no easy way the compiler could figure that out, as it is
> determined by whether you modify "i" anywhere else in the body of the loop
> (including potentially within called subprograms via an alias), and by the
> implementation of that library "++" routine (which you could have even
> overridden, for all it knows).

    No, you can't overload an operator that is already defined. I
couldn't overload vector::iterator::operator++(), even if I wanted to.

> None of this is an issue for an Ada compiler, because "i" *can't* be
> (legally) modified at all.


-- 
Clark S. Cox III
clarkcox3@yahoo.com
http://www.whereismyhead.com/clark/

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

[Bart.Vanhauwaert]

Ted Dennison <dennison@telepath.com> wrote:
> 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?

In C++ the programmer explicitly tells the compiler if a member
function needs to be dynamically-dispatchable. (virtual). Overloaded
operators however are never dynamically-dispatchable.

And anyway, even if we didn't use the pre-increment operator but
our own do_incr() member which we did make virtual, dynamic-
dispatch wouldn't be applicable since the control variable
is not a pointer to an object or a reference but an object. In
that case runtime type = compiletime type and hence the compiler
knows which member to call.

> Well, that's easy to *say*. But if your compiler can't inline dispatching calls,
> and "++" is a dispatching call, then it won't get inlined, and you will have
> procedure call overhead for every increment. This isn't an issue at all for Ada

Well, it is easy to *say* if you know how it works. There is no
dynamic dispatch here and thus inlining is perfectly possible.

> "for" loops, because the incrementing is *implicit*. Well...to be truthful,
> you'd have the same issue with Ada if you used some abstract tagged private type
> in a "while" loop instead, which would be a direct translation of what you've
> done in C++. But in Ada you don't need to do that just to get type safety. The
> base types already have it (if you don't disable it).

Exactly for cases as this, you can
put implementations of potentially inlineable members in the headers.
That way the compiler has seen all information it needs to easily
decide when (and how) to inline.

> Quite true. The difference is that its much *easier* for an Ada compiler to do
> this, becuse far more of the nessecary information is available to the optimizer

There is no question that writing a good optimizing C++ compiler is a
VERY difficult task. Some come close but none are optimal. However,
this is one of the easier cases to optimize. You are not doing your
case any good by insisting that this might be a problem in the
real world. There are a lot of things which are a lot harder and
where a critique for C++ as a difficult to optimize language is
much more appropriate.

> at compile time. For instance, its tough to fully unroll a loop, if you don't

Given modern CPU's it is actually a loss to agressively unroll
or inline. ichache pressure and such does that to you. In a lot
of cases a missed cache hit is much more costly than a simple,
easy to branch predict call.

cu bart

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

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

[Stefan Skoglund]

Bart.Vanhauwaert@nowhere.be wrote:
> Given modern CPU's it is actually a loss to agressively unroll
> or inline. ichache pressure and such does that to you. In a lot
> of cases a missed cache hit is much more costly than a simple,
> easy to branch predict call.

Nothing is modern about a MilStd 1750 CPU !!

Remember that a number of people on comp.lang.ada is 
embedded system programmers which must adopt to some
very restricted platforms.

Does it exist any intel offerings now which is RadHard ?

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

[Marin David Condic]

If Intel did offer some version of their 80x86 family in a deep-space,
gamma-ray, rad-hard version it might not replace the tried and true
Mil-Std-1750a. (Although I don't know if anyone is still making one of these
for deep space.) One of the beauties of the 1750a was the indivisible nature
of the instructions, their simplicity and predictability. For hard-realtime
apps, it was really nice because it was a lot easier to build something with
predictable timing and with a high level of verifiability. I'd love to see
something like it only with a larger address space. I heard tell (before
getting out of the deep space business) that Honeywell had a rad-hard
product - the RH-32 - that aimed to take the place of the aging and
increasingly scarce 1750, but I don't know of any deep space apps that are
using it. (Just ignorance on my part - like I said - I'm out of that
business...) It would be nice to know what designers are using these days
instead of the 1750 for deep space and to have a look at the architecture to
see what they did with cache, etc.

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/


"Stefan Skoglund" <stetson@ebox.tninet.se> wrote in message
news:3B784DCB.A3BF419D@ebox.tninet.se...
>
> Nothing is modern about a MilStd 1750 CPU !!
>
> Remember that a number of people on comp.lang.ada is
> embedded system programmers which must adopt to some
> very restricted platforms.
>
> Does it exist any intel offerings now which is RadHard ?
>

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

[Stefan Skoglund]

Marin David Condic wrote:
> business...) It would be nice to know what designers are using these days
> instead of the 1750 for deep space and to have a look at the architecture to
> see what they did with cache, etc.

Someone was talking about a radhard SPARC variant.
It probably implements sparc v 7 instruction set.

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

[Bart.Vanhauwaert]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> 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.

The STL is an inherent part of the C++ Language. I have before me
International Standard ISO/IEC 14882 (Programming languages - C++)
chapter 17 up to chapter 27 are dedicated to the different
libraries that are part of C++. There is no denying they are part
of standard C++. (And they are part of what made me choose C++
over C btw)

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

Look, you obviously don't know C++ that well, so please refrain from
going into details and trying to pin C++ as a potentially
non-optimizeable language on your assumptions which are FALSE.
There is no question of virtual dispatch in this case as any
junior C++ programmer will be able to tell you.

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

So what? Does that matter for me, as a user of the platform? Not
at all. So it doesn't enter the balance of advantages/disadvantages
of C++.

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:
> > 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.
> 
> The STL is an inherent part of the C++ Language. I have before me
> International Standard ISO/IEC 14882 (Programming languages - C++)
> chapter 17 up to chapter 27 are dedicated to the different
> libraries that are part of C++. There is no denying they are part
> of standard C++. (And they are part of what made me choose C++
> over C btw)

Pardon me? Are you saying you cannot get a C++ compiler without a
STL? Don't be silly.

> > It is true that unless they did something wacky like make it virtual, the
> > C++ inline ++ operator is usually cheap.
> 
> Look, you obviously don't know C++ that well, so please refrain from
> going into details and trying to pin C++ as a potentially
> non-optimizeable language on your assumptions which are FALSE.
> There is no question of virtual dispatch in this case as any
> junior C++ programmer will be able to tell you.

You've got attitude... I'll give you that.

> > 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.
> 
> So what? Does that matter for me, as a user of the platform? Not
> at all. So it doesn't enter the balance of advantages/disadvantages
> of C++.

I can see that having a meaningful dialog with you on this subject is
extremely difficult. I'm on vacation, and this will be my last post
on this tired thread.
-- 
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:
>> The STL is an inherent part of the C++ Language. I have before me
>> International Standard ISO/IEC 14882 (Programming languages - C++)
>> chapter 17 up to chapter 27 are dedicated to the different
>> libraries that are part of C++. There is no denying they are part
>> of standard C++. (And they are part of what made me choose C++
>> over C btw)
> Pardon me? Are you saying you cannot get a C++ compiler without a
> STL? Don't be silly.

A standard-conforming hosted C++ compiler MUST somehow include the STL.

>> > It is true that unless they did something wacky like make it virtual, the
>> > C++ inline ++ operator is usually cheap.
>> Look, you obviously don't know C++ that well, so please refrain from
>> going into details and trying to pin C++ as a potentially
>> non-optimizeable language on your assumptions which are FALSE.
>> There is no question of virtual dispatch in this case as any
>> junior C++ programmer will be able to tell you.
> You've got attitude... I'll give you that.

If you keep on saying that there is virtual dispatch in this line
of code (we began the discussion with it)

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

I will have to keep on correcting you.

> I can see that having a meaningful dialog with you on this subject is
> extremely difficult. I'm on vacation, and this will be my last post
> on this tired thread.

You've been saying this for 4 posts know. It's difficult to let go
of a good thread, isn't it :)

cu bart

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

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

[Matthew Woodcraft]

Bart.Vanhauwaert@nowhere.be writes:

> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> > Pardon me? Are you saying you cannot get a C++ compiler without a
> > STL? Don't be silly.
> 
> A standard-conforming hosted C++ compiler MUST somehow include the STL.

Out of interest, are there any fully standard-conforming C++ compilers
yet?

-M-

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.

[Kaz Kylheku]

In article <3B7C6977.3648F061@home.com>, Warren W. Gay VE3WWG wrote:
>> 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.

The standard template library is defined in the same document  as the
rest of the C++ language. That document specifies the form and
semantic interpretation of C++ programs, including C++ programs
which use the STL component of the language.

There is some string of symbols which we call a C++ program, and that
string may contain things like #include <set> and map<int>::iterator.
Those things have a standard interpretation in the C++ standard.

>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

So what? The C++ language existed long before namespaces and exception
handling came along. So these are not part of C++ either?

You simply have a narrow, weak idea of what constitutes a language.

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

[pete]

Kaz Kylheku wrote:
> 
> In article <3B7C6977.3648F061@home.com>, Warren W. Gay VE3WWG wrote:
> >> 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.
> 
> The standard template library is defined in the same document  as the
> rest of the C++ language. That document specifies the form and
> semantic interpretation of C++ programs, including C++ programs
> which use the STL component of the language.
> 
> There is some string of symbols which we call a C++ program, and that
> string may contain things like #include <set> and map<int>::iterator.
> Those things have a standard interpretation in the C++ standard.
> 
> >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
> 
> So what? The C++ language existed long before namespaces and exception
> handling came along. So these are not part of C++ either?
> 
> You simply have a narrow, weak idea of what constitutes a language.

"The standard library is not part of the C language proper,
but an environment that supports standard C will provide
the function declarations and type and macro definitions 
of this library."

K&R2 appendix B

-- 
 pete

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

[Richard Bos]

pete <pfiland@mindspring.com> wrote:

> "The standard library is not part of the C language proper,
> but an environment that supports standard C will provide
> the function declarations and type and macro definitions 
> of this library."
> 
> K&R2 appendix B

That's probably a leftover from the days of K&R 1, when it was true. In
ISO C, the Standard describes both the grammar and the library, and both
are part of the language.

Richard

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

[pete]

Richard Bos wrote:
> 
> pete <pfiland@mindspring.com> wrote:
> 
> > "The standard library is not part of the C language proper,
> > but an environment that supports standard C will provide
> > the function declarations and type and macro definitions
> > of this library."
> >
> > K&R2 appendix B
> 
> That's probably a leftover from the days of K&R 1, 
> when it was true. In ISO C, the Standard describes both the grammar
> and the library, and both are part of the language.

Then the phrases 
   "language and library" (C99)
and
   "language or library" (old C)
are unperspicuosly verbose where they appear in the standard.

-- 
 pete

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

[pete]

Richard Bos wrote:
> 
> pete <pfiland@mindspring.com> wrote:
> 
> > "The standard library is not part of the C language proper,
> > but an environment that supports standard C will provide
> > the function declarations and type and macro definitions
> > of this library."
> >
> > K&R2 appendix B
> 
> That's probably a leftover from the days of K&R 1, 
> when it was true. In ISO C, the Standard describes both the grammar 
> and the library, and both are part of the language.

My old C standard draft says:
"The Committee divided the effort into three pieces: the
environment, the language, and the library.  A complete specification
in each of these areas is necessary if truly portable programs are to
be developed.  Each of these areas is addressed in the Standard."

In the new standard:
section 5 is Environment
section 6 is Language 
section 7 is Library

-- 
 pete

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

[Kaz Kylheku]

In article <3B7CE3E1.6F80@mindspring.com>, pete wrote:
>Kaz Kylheku wrote:
>> You simply have a narrow, weak idea of what constitutes a language.
>
>"The standard library is not part of the C language proper,

``C language proper'' !=  ``C language''.

Nice try!

>but an environment that supports standard C will provide
>the function declarations and type and macro definitions 
>of this library."
>
>K&R2 appendix B

Written by people with a clue.

And also note that the standard C library did originate as a separate
project: a user space library for general programming on UNIX.  Much of
that library was standardized by a group of people called /usr/group.
Their definition was split into parts that went into C and that went into
POSIX. So *historically*, it was true that the library was a separate
entity. It was codified into the language.

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

[pete]

Kaz Kylheku wrote:
> 
> In article <3B7CE3E1.6F80@mindspring.com>, pete wrote:
> >Kaz Kylheku wrote:
> >> You simply have a narrow, weak idea of what constitutes a language.
> >
> >"The standard library is not part of the C language proper,
> 
> ``C language proper'' !=  ``C language''.
> 
> Nice try!

I'll give it one more go:

"C language proper" in K&R == "language" in the standard

-- 
 pete

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

[Kaz Kylheku]

In article <3B80B5F2.B76@mindspring.com>, pete wrote:
>Kaz Kylheku wrote:
>> 
>> In article <3B7CE3E1.6F80@mindspring.com>, pete wrote:
>> >Kaz Kylheku wrote:
>> >> You simply have a narrow, weak idea of what constitutes a language.
>> >
>> >"The standard library is not part of the C language proper,
>> 
>> ``C language proper'' !=  ``C language''.
>> 
>> Nice try!
>
>I'll give it one more go:
>
>"C language proper" in K&R == "language" in the standard

Ah, so when in the introduction, the standard says that it ``specifies
the the form and establishes the interpretation of programs written in
the C programming language'', that only means programs which don't use
the standard library.  And in the title of the document, ``Programming
Languages---C'' refers to only half the document. It's all clear now!

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

[Kaz Kylheku]

In article <3B7C79FA.89E62321@globetrotter.qc.ca>, Chris Wolfe wrote:
>> 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.

In fact, when you write your own procedures or functions, you are
extending the language to create a new dialect specific to your program.

When I write a C program that has a function int foo(void), then I have
a new dialect which includes standard things like getchar(), plus the name
foo, which is understood to have a certain meaning within
the small ``community'' of my program's modules.

The distinction between library and ``language core'' may be somewhat
easy to make in some languages, but there are others which defy it.
For example, in a language like Lisp, it's not possible to pin down
what the core is and what is built up using that core. It depends
greatly on the implementor.

To an extent this is true of languages like C. Some implementations
of C treat certain functions like abs() or memcpy() effectively as
built-in operators, rather than as external function calls to a library
that is linked to the program.  And the opposite can be true: the use
of a built-in language feature like, say, a division operator can be
translated into a call to a ``run-time support'' library.

So ultimately, the division between ``library'' and ``core'' is simply
a pragmatic one that is of interest primarily to implementors, who
must decide how the language implementation is going to be organized.
Bot are simply implementation artifacts which support the interpretation
of programs written in a language.

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

[Warren W. Gay VE3WWG]

Kaz Kylheku wrote:
> In article <3B7C79FA.89E62321@globetrotter.qc.ca>, Chris Wolfe wrote:
> >> 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.
> 
> In fact, when you write your own procedures or functions, you are
> extending the language to create a new dialect specific to your program.

Rubbish. You are _using_ the language to create a translation (compiled
output).

When you can show the compiler's yacc grammer that specifically 
addresses specific aspects of the STL (ie. specific to certain
class names), then you might have something.

Until then, you are calling sheep goats.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Kaz Kylheku]

In article <3B7C9288.6CD8C288@home.com>, Warren W. Gay VE3WWG wrote:
>Kaz Kylheku wrote:
>> In article <3B7C79FA.89E62321@globetrotter.qc.ca>, Chris Wolfe wrote:
>> >> 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.
>> 
>> In fact, when you write your own procedures or functions, you are
>> extending the language to create a new dialect specific to your program.
>
>Rubbish. You are _using_ the language to create a translation (compiled
>output).

The language needn't be compiled. What I'm doing is expressing that
a computation is to take place.

>When you can show the compiler's yacc grammer that specifically 
>addresses specific aspects of the STL (ie. specific to certain
>class names), then you might have something.

The C++ language is no defined by a yacc grammar.

Its grammar does have non-terminal symbols which refer to previously
declared entities, and which are not specific to certain class
names. 

There is no doubt that a correctly written C++ program which uses the
standard template library is grammatical. If that program contains
#include <map>, that is a well-formed preprocessing directive
which refers to a standard-defined header.  The grammar for that
directive does not have ``map'' as a hard-coded terminal symbol in it.
That symbol is part of the lexicon of the language.  Similarly,
the grammar does not have a specific production for map<int,
double>::iterator.

>Until then, you are calling sheep goats.

I'm not going to demand that you accept the definitions of the terms that
I'm using. But those definitions are not confused.  It is your definition
that is confused: you are confusing ``grammar'' and ``language''. Only in
the narrowest mathematical sense is a language the regular set generated
by a grammar.

In the terminology that I'm using, a programming language is a broader
container which contains components like ``grammar'' and ``library''.

To call the language a grammar is to mistake the part for the whole.

You can use whatever definitions you want; I only wanted to advise you
that the definitions you are using are not generally accepted by everyone,
so you are likely to create confusion in future debates, and invite
repeated corrections.   With that I'm out; the last thing I'm interested
in is a drawn out dispute about the semantics of some words!

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

[Warren W. Gay VE3WWG]

Kaz Kylheku wrote:
> In article <3B7C9288.6CD8C288@home.com>, Warren W. Gay VE3WWG wrote:
> >Kaz Kylheku wrote:
> >> In article <3B7C79FA.89E62321@globetrotter.qc.ca>, Chris Wolfe wrote:
> >> >> 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.
> >>
> >> In fact, when you write your own procedures or functions, you are
> >> extending the language to create a new dialect specific to your program.
> >
> >Rubbish. You are _using_ the language to create a translation (compiled
> >output).
> 
> The language needn't be compiled. What I'm doing is expressing that
> a computation is to take place.
> 
> >When you can show the compiler's yacc grammer that specifically
> >addresses specific aspects of the STL (ie. specific to certain
> >class names), then you might have something.
> 
> The C++ language is no defined by a yacc grammar.

I'd be _real_ surprised if gcc does not use yacc to implement the C++
compiler. But even so, then let's move on..

> >Until then, you are calling sheep goats.
> 
> I'm not going to demand that you accept the definitions of the terms that
> I'm using. But those definitions are not confused.  It is your definition
> that is confused: you are confusing ``grammar'' and ``language''. Only in
> the narrowest mathematical sense is a language the regular set generated
> by a grammar.
> 
> In the terminology that I'm using, a programming language is a broader
> container which contains components like ``grammar'' and ``library''.
> 
> To call the language a grammar is to mistake the part for the whole.

I agree with you on this, but you are putting words in my mouth. The
grammer does indeed help to define the language (its form and its
rules), but obviously is not the language itself. 

But what about this: What language does the STL use?
Hmmm.. lemme guess, it's probably C++ and perhaps a sprinkling of
assembler where required for ultimate speed. After all, the STL
is a _translated_ library, that is shipped with "include" files.
Again, the "include" files are written in C++.

But wait a minute? You cannot define something in terms of itself.
So this leads to one of two conclusions:

The language that the STL is written in is:

  - a subset of C++
  - or the STL is not part of the C++ language proper. As such, it 
    only enhances the usefulness of the C++ language, as a _library_

I have yet to hear of anyone talk about "subset C++". So while you
have some points, I still cannot agree with you on this point.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Kaz Kylheku]

In article <3B7D2033.1C780DF5@home.com>, Warren W. Gay VE3WWG wrote:
>Kaz Kylheku wrote:
>> In article <3B7C9288.6CD8C288@home.com>, Warren W. Gay VE3WWG wrote:
>> >When you can show the compiler's yacc grammer that specifically
>> >addresses specific aspects of the STL (ie. specific to certain
>> >class names), then you might have something.
>> 
>> The C++ language is no defined by a yacc grammar.
>
>I'd be _real_ surprised if gcc does not use yacc to implement the C++
>compiler. But even so, then let's move on..

GCC uses bison. GCC does not define the C++ language.

>> In the terminology that I'm using, a programming language is a broader
>> container which contains components like ``grammar'' and ``library''.
>> 
>> To call the language a grammar is to mistake the part for the whole.
>
>I agree with you on this, but you are putting words in my mouth. The
>grammer does indeed help to define the language (its form and its
>rules), but obviously is not the language itself. 
>
>But what about this: What language does the STL use?

Use in what sense? The library is kind of lexicon which makes available
certain identifiers in certain categories. These categories come
from the C++ syntax.

Because those identifiers are available, the rest of my program which
uses those identifers has a meaning which can be inferred from the
semantic descriptions of those identifers in the standard.

>Hmmm.. lemme guess, it's probably C++ and perhaps a sprinkling of
>is a _translated_ library, that is shipped with "include" files.
>Again, the "include" files are written in C++.

I can't infer this requirement in the C++ standard. Can you cite
a reference that standard headers must be files that are written in C++,
or that there must must exist previously translated libraries
as visible components?

As far as I can tell, when you write #include <iostream> that is
simply a magic incantation which makes certain identifiers
available. Those identifiers behave ``as if'' they were introduced
by C++ declarations.

>But wait a minute? You cannot define something in terms of itself.
>So this leads to one of two conclusions:
>
>The language that the STL is written in is:

The language that the library it's written in is English. How it's
implemented is just an artifact of an implementation. Such artifacts do
not define the language and do not necessarily provide a framework for
clear, platform-independent reasoning about a language.

Note that many components of a standard library cannot be written in
that language. Only their interface can be expressed as a declaration
that language. (How can you write, say, the time() function in C
without invoking some platform-specific system service, or
accessing clock hardware?)  

The C99 standard has introduced a new header containing type-generic
macros for math functions <tgmath.h>. There is no way to write these
type-generic macros in C99! So tell me, what language are they
``written'' in?

Lastly, same languages have very little syntax at all; everything is
done with standard functions, or forms that resemble them. You could
argue that (cons ...) is not part of Lisp, but merely a library function
for constructing and initializing a cons cell; the only things that are
part of the language are parentheses, macro characters, quotes and a few
other elements of the read syntax. Yet, the majority of programs would
lose their meaning if (cons) were removed. There are special operators,
but any of those could be implemented using macros. So there is no way
to draw the division about what is core and what can be implemented as a
library. The syntax alone doesn't provide that core, because you'd have
nothing to bootstrap with. There are may ways of choosing the core subset
of special forms that will be intrinsic; it's an implementation choice.

>  - or the STL is not part of the C++ language proper. As such, it 
>    only enhances the usefulness of the C++ language, as a _library_
 
``language proper'' is just a synonym for ``grammar'' or ``syntax''.
It's not a synonym for ``language''.
 
Look, why don't you try to convince people on the street that ``water''
is not really part of the English language, because it's doesn't play
a role in the syntax?

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

[Warren W. Gay VE3WWG]

Kaz Kylheku wrote:
> In article <3B7D2033.1C780DF5@home.com>, Warren W. Gay VE3WWG wrote:
> >Kaz Kylheku wrote:
> >> In article <3B7C9288.6CD8C288@home.com>, Warren W. Gay VE3WWG wrote:
> >> >When you can show the compiler's yacc grammer that specifically
> >> >addresses specific aspects of the STL (ie. specific to certain
> >> >class names), then you might have something.
> >>
> >> The C++ language is no defined by a yacc grammar.
> >
> >I'd be _real_ surprised if gcc does not use yacc to implement the C++
> >compiler. But even so, then let's move on..
> 
> GCC uses bison. GCC does not define the C++ language.

Oh, whine about big differences please. Bison is a yacc
knock-off if you havn't noticed. Good grief.. I don't believe
I had to address that here.

And of course GCC does not define the C++ language -- stop putting
words in my mouth.  But GCC is a good implementation to look at,
since source code is readily available for it.

> >> In the terminology that I'm using, a programming language is a broader
> >> container which contains components like ``grammar'' and ``library''.
> >>
> >> To call the language a grammar is to mistake the part for the whole.
> >
> >I agree with you on this, but you are putting words in my mouth. The
> >grammer does indeed help to define the language (its form and its
> >rules), but obviously is not the language itself.
> >
> >But what about this: What language does the STL use?
> 
> Use in what sense?

What is it written in?

> The library is kind of lexicon which makes available
> certain identifiers in certain categories. These categories come
> from the C++ syntax.

You tried hard not to say "language" here, didn't you =)

> Because those identifiers are available, the rest of my program which
> uses those identifers has a meaning which can be inferred from the
> semantic descriptions of those identifers in the standard.

Bzzzt! None of those identifiers would have any meaning without 
a language that defines how they are assembled together.

> >Hmmm.. lemme guess, it's probably C++ and perhaps a sprinkling of
> >is a _translated_ library, that is shipped with "include" files.
> >Again, the "include" files are written in C++.
> 
> I can't infer this requirement in the C++ standard. Can you cite
> a reference that standard headers must be files that are written in C++,
> or that there must must exist previously translated libraries
> as visible components?

Again, tell me what you call the source code that is contained in
the header files. Their written in C++ of course.

> As far as I can tell, when you write #include <iostream> that is
> simply a magic incantation 

Magic now?

> which makes certain identifiers
> available. Those identifiers behave ``as if'' they were introduced
> by C++ declarations.

Again, none of those declarations would have any value if there were
no language predefined that identified how they were assembled and
put together to create a translation (which is the object of this
process).

> >But wait a minute? You cannot define something in terms of itself.
> >So this leads to one of two conclusions:
> >
> >The language that the STL is written in is:
> 
> The language that the library it's written in is English. 

Oh... so now someone is using a "English-to-object code translater"
to produce your STL libraries now?  You mean your STL is not written
in any computer language? Don't be rediculous.

> How it's
> implemented is just an artifact of an implementation.

I'll concede that your STL could have been entirely written in Ada, or
assembler language. But we both know that no implementation of it will
be done that way. You say its unimportant. I say its very important
to this discussion, but you don't want to face it because it works
against your argument.

> Such artifacts do
> not define the language and do not necessarily provide a framework for
> clear, platform-independent reasoning about a language.
> 
> Note that many components of a standard library cannot be written in
> that language. Only their interface can be expressed as a declaration
> that language. (How can you write, say, the time() function in C
> without invoking some platform-specific system service, or
> accessing clock hardware?)

I already said that parts of it will not be C++. So what's your point?

> The C99 standard has introduced a new header containing type-generic
> macros for math functions <tgmath.h>. There is no way to write these
> type-generic macros in C99! So tell me, what language are they
> ``written'' in?

I have to confess ignorance on this feature, because I have not seen
this C99 feature yet.

> Lastly, same languages have very little syntax at all; 

But we're not talking about some languages, but C++.

> everything is
> done with standard functions, or forms that resemble them. 

But even they have a language (which includes rules, grammer) that 
defines how those functions are invoked.

> You could
> argue that (cons ...) is not part of Lisp, but merely a library function
> for constructing and initializing a cons cell; the only things that are
> part of the language are parentheses, macro characters, quotes and a few
> other elements of the read syntax. Yet, the majority of programs would
> lose their meaning if (cons) were removed. There are special operators,
> but any of those could be implemented using macros. So there is no way
> to draw the division about what is core and what can be implemented as a
> library.

I know what you're saying above, but this last statement is simply
rubbish. Admitedly, there are some grey areas but as a practicle
concession, everyone (else) uses a division between language and library
for very practicle reasons. You for some reason, have an aversion to it.

> The syntax alone doesn't provide that core, because you'd have
> nothing to bootstrap with. There are may ways of choosing the core subset
> of special forms that will be intrinsic; it's an implementation choice.

But without the core language, and a compiler that supports it, you
cannot compile your STL _library_. The STL is written in something,
which is not English. I mean, what do
you call that source code that makes up the STL? Not english, not object
code, hmmm, source language code, yes-- and what source code is 
that? -- its C++.

> >  - or the STL is not part of the C++ language proper. As such, it
> >    only enhances the usefulness of the C++ language, as a _library_
> 
> ``language proper'' is just a synonym for ``grammar'' or ``syntax''.
> It's not a synonym for ``language''.

So you say... but that is not completely what I said.

In conclusion, and this will be my last word on it, since I can already
see that whatever I post here, you'll just reject anyway. For the
benefit of the other readers, I'll just conclude with this thought,
and move on:

I know the point that you are making.. yes, there is a sense that 
libraries and other tools (macros) enhance the use of the "facility", 
if you will. Language standards may even mandate that certain library
facilities be provided (as does Ada95), but you'll note that these
documents usually recognize that these components are library components
(or macro facilities).

So there is still a practical distinction between the language and 
the libraries, even though they may be specified in a language standard,
or standards document.

As someone else has pointed out, the standards committees have already
made these distinctions between language, library and environment(?).
This by itself shows a practical recognition by the defining standards
committe that these are valid classifications to make, and used for 
very practical purposes. 
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Kaz Kylheku]

In article <3B7DFA37.70534817@home.com>, Warren W. Gay VE3WWG wrote:
>Kaz Kylheku wrote:
>> >The language that the STL is written in is:
>> 
>> The language that the library it's written in is English. 
>
>Oh... so now someone is using a "English-to-object code translater"
>to produce your STL libraries now?  You mean your STL is not written
>in any computer language? Don't be rediculous.

It's not necessarily written in C++, that is the point. It could be
written, for instance, in the binary language of the compiler's symbol
table and syntax tree data structures. When you write #include <map>,
the compiler could load a binary image containing cooked symbol tables.
Or it could have such structures already within its bowels, and simply
make them available to the program.  Standard headers do not have to be
source files, and they do not have to be files. You have made several
incorrect references to ``header files''.

If you take away the template library, you are left with a subset of
the standard C++ language. That subset is still a language.  The template
library can be bootstrapped using only that remaining subset. So what?
That remaining subset is useful for programming without the library. 
So what?

Then you are saying that whenever some feature of a language can
be implemented in terms of other features, that feature is not
part of the language. Is this an accurate account of the proposition
that you are making? If it isn't, how would you reformulate
the proposition?

That proposition, as stated, fails on languages in which one cannot
identify any single possible core sublanguage that can bootstrap
everything else.  In such languages it so happens that language feature
A could be implemented in terms of language feature B, but B could also
be implemented in terms of A.  So which one is intrinsic, and which one
is the boostrapped addition?

Also, according to the proposition, the while loop must not be part
of the C++ language, because it can be defined as:

	#define while (X) for (;(X);)

Are you comfortable with this conclusion?

It's easier to simply say that all of the elements that are required
in order to give an interpretation of programs written in a language,
are part of that language, even if some of them are redundant.

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

[David Thompson]

Kaz Kylheku <kaz@ashi.footprints.net> wrote :
[ in YA debate about "core language" vs "library " ]
...
> Then you are saying that whenever some feature of a language can
> be implemented in terms of other features, that feature is not
> part of the language. Is this an accurate account ...?
> Also, according to the proposition, the while loop must not be part
> of the C++ language, because it can be defined as:
>
> #define while (X) for (;(X);)
>
Not with a space between the macroname and paramlist.
And even fixing that a strictly-conforming program can tell
it's #define'd, and it doesn't work if the while condition uses
the comma operator (misparsed as a punctuator).
You would need something like C99 (or GNU) vararg-macros,
plus a feature something like #pragma hiddendefine.

Of course if would work if done by compiler (or preprocessor?)
magic, being pre-set appropriately in the internal symbol table
so that it produces the effect you intended -- but is that really
different from a compiler that just parses a while statement
and transforms the internal parse tree to be the same as a
for statement with only a condition, which sounds to me like
a perfectly reasonable implementation technique?

--
- David.Thompson 1 now at worldnet.att.net

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

[Kaz Kylheku]

In article <oBZi7.624$151.47802@bgtnsc05-news.ops.worldnet.att.net>,
David Thompson wrote:
>Kaz Kylheku <kaz@ashi.footprints.net> wrote :
>[ in YA debate about "core language" vs "library " ]
>...
>> Then you are saying that whenever some feature of a language can
>> be implemented in terms of other features, that feature is not
>> part of the language. Is this an accurate account ...?
>> Also, according to the proposition, the while loop must not be part
>> of the C++ language, because it can be defined as:
>>
>> #define while (X) for (;(X);)
>>
>Not with a space between the macroname and paramlist.

Sorry about that! Typing a space after the while keyword is a stylistic
habit that is hard to break.

>And even fixing that a strictly-conforming program can tell
>it's #define'd, and it doesn't work if the while condition uses
>the comma operator (misparsed as a punctuator).

These are all nitpicks. Sure you can tell, but the point is that if C
had for loops but not while loops, you could construct them like this,
and it would be quite effective.  This observation was intended to
support my argument against the view that any language feature which can
be effectively constructed from the remaining subset of a language is
not part of that language.

In some languages, macros are a lot cleaner; they can much more
``seamlessly'' implement new language features. Any system of reasoning
about languages should generalize to these languages.

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

[Bart.Vanhauwaert]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> The language that the STL is written in is:
>   - a subset of C++
>   - or the STL is not part of the C++ language proper. As such, it 
>     only enhances the usefulness of the C++ language, as a _library_

It could very well be that the STL of a certain implementation
(conforming!) is written in Ada. There is no way to tell from
a standard point of view.

cu bart

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

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

[Ian]

kaz@ashi.footprints.net (Kaz Kylheku) wrote in message news:<hN3f7.72776$B37.1689670@news1.rdc1.bc.home.com>...

> 
> The C++ language is no defined by a yacc grammar.
> 

Did you say that it is noW defined or noT defined?
Does any one have a formal definition of the C++ language definition 
in some formal language?

That is for C++ (ISO 14882:1998) or for something that is close.

I would find that very useful.

Thanks, Ian

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

[Matthew Austern]

pete <pfiland@mindspring.com> writes:

> Then the phrases 
>    "language and library" (C99)
> and
>    "language or library" (old C)
> are unperspicuosly verbose where they appear in the standard.

In C++, at least, we tend to talk about the "core language" and the
"library".  It's possible to distinguish between them, but they're
described in the same document (ISO/IEC 14882) and the boundaries
between them get a bit fuzzy around the edges.  Some important
features, like typeid, lie right on the boundary.

Also true in C90 and C99, of course.  Do you consider setjmp/longjmp
core language, or library?  And how about the new C99 generic math
functions, which can't be implemented without some kind of compiler
magic?  

I'm not picking on C++, or C90, or C99; I could come up with similar
examples in Eiffel or Java.  My real claim is that, while it's fine to
talk about "language and library" in an informal sense, or for
organizational purposes, it probably isn't all that useful to try to
draw a sharp line between them.

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

[Ted Dennison]

In article <r1nuk9.2ua.ln@10.0.0.2>, Bart.Vanhauwaert@nowhere.be says...
>
>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)

I don't do C++ much, but it does happen. So I'm certianly putting it in my
bag-o-tricks (speed be damned).

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

There is no (legal) possibility of aliasing, so it can *always* be kept in a
register. If the bounds are static (which they ususally are in an Ada "for" loop
that iterates through an array), it can even figure out at compile time exactly
how many loops there will be, and unroll (or not) accordingly. A really clever
optimizer might even be able to do sexy stuff like set the BPU to the right
value just before the loop is ready to fall out. All this can be done with C++
too, of course. But it would be a lot more work for the compiler to figure out
if it would be safe to do so.

>> Also, remember that all of us are not application programmers. Marin and I 
>> are systems programmers. I get quite suspicous of any *dynamic* data 
>I guess that's why you use Ada and I use C++? Best tool for the job
>and all that?

I suppose you could say that. But then, Ada doesn't exactly have problems with
dynamic data structures either. It just doesn't require them in a lot of places
where C does. There's still nothing stopping you from using them if you really
want to. You just have more options. However, I do have to admit that Ada is
really more of a "dream language" for systems programmers. For applications, it
drops down to meerly being a fair bit better. :-)  (Which isn't really enough
for a lot of people)

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

I'll admit it is quite possible, in theory, to have nice predicitable allocators
and deallocaters. But for the most part, real-time programmers (and kernel
programmers, I'd imagine) avoid *any* dynamic allocations at all during runtime
like the plague. Even a good regular memory manager is going to take much longer
than a stack allocation and/or deallocation (which just involves moving the
stack pointer). To make matters worse, most OS'es (even RTOSes) *don't* come
with a good one. Thus all data typically gets allocated either at startup time,
or on the stack at runtime. Where I work, having a runtime dynamic memory op
discovered in your code is typically a one-way ticket to the doghouse. :-)

>> Systems software is pretty much what this thread is about. In particular, one
>Is it? I approached this thread from the application programming side.

Well, the topic is avoiding security problems like the Code Red worm. Worms like
this one use security holes in the OS (and near-OS systems software like email
servers and webservers). So yes, it is pretty much all about not using unsafe
languages to write Systems Software.

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

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

[Dan Cross]

In article <slrn9mlqp3.56q.randhol+abuse@kiuk0156.chembio.ntnu.no>,
Preben Randhol <randhol+abuse@pvv.org> wrote:
>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.

Yes, exactly.  And I would go farther and say that on today's zippy
microprocessors, the difference is even less than that.  I imagine
that the performance of Ada and say C++ is roughly the same.

	- Dan C.

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.

[Gerhard Häring]

On Mon, 6 Aug 2001 16:56:23 +0000 (UTC), Preben Randhol wrote:
>Use Ada 95, a free language. More info at http://www.adapower.com/

How can a *language* be free? An implementation, yes. A language, not in any
way I could imagine.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://highqualdev.com              public key at homepage
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y: x+y, [chr(ord(x)^42) for x in list('zS^BED\nX_FOY\x0b')])

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

[Kaz Kylheku]

In article <6ejmk9.f11.ln@gargamel.hqd-internal>, Gerhard H�ring wrote:
>On Mon, 6 Aug 2001 16:56:23 +0000 (UTC), Preben Randhol wrote:
>>Use Ada 95, a free language. More info at http://www.adapower.com/
>
>How can a *language* be free? An implementation, yes. A language, not in any
>way I could imagine.

I can imagine a few ways. For instance, you can be free to implement
the language and base the name of your implementation on the name of that
language, without bringing a trademark infringement lawsuit on yourself.
It can be free in the sense that you can obtain a freely distributed
document that specifies it.

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

[Preben Randhol]

On Mon, 06 Aug 2001 17:34:40 GMT, Kaz Kylheku wrote:
> In article <6ejmk9.f11.ln@gargamel.hqd-internal>, Gerhard H�ring wrote:
>>On Mon, 6 Aug 2001 16:56:23 +0000 (UTC), Preben Randhol wrote:
>>>Use Ada 95, a free language. More info at http://www.adapower.com/
>>
>>How can a *language* be free? An implementation, yes. A language, not in any
>>way I could imagine.

Hmm perhaps that signature line is a bit ambiguous yes. I was thinking in
the way Java isn't free, but I'll rethink it...

> I can imagine a few ways. For instance, you can be free to implement
> the language and base the name of your implementation on the name of that
> language, without bringing a trademark infringement lawsuit on yourself.
> It can be free in the sense that you can obtain a freely distributed
> document that specifies it.

Which is the case with Ada. It is ISO standardised (actually the first
OOP language) it has the Rational, Reference Manual and the
Quality and Style Guide freely available on the net and you can
distribute them as you like. Usually you have to buy these documents.

Ada 95 Reference Manual: 
http://www.adapower.com/rm95/index.html

Ada 95 Rational : 
http://www.adapower.com/rationale/index.html

Ada 95 Quality and Style Guide:
http://www.informatik.uni-stuttgart.de/ifi/ps/ada-doc/style_guide/cover.html

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.

[Ben Pfaff]

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

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

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

That's a pretty hostile attitude to take in comp.lang.c.  Are you
trolling?

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

[Preben Randhol]

On 06 Aug 2001 15:42:26 -0400, Ben Pfaff wrote:
> randhol+abuse@pvv.org (Preben Randhol) writes:
> 
>> -- 
>> �Don't use C;  In my opinion,  C is a library programming language
>>  not an app programming language.�  - Owen Taylor (GTK+ developer)
> 
> That's a pretty hostile attitude to take in comp.lang.c.  Are you
> trolling?

No I'm not trolling. I only quote a C user. :-) But I can put a
different signature if you feel offended.

Preben
-- 
�If you had just boarded an airliner and discovered that your team 
 of programmers had been responsible for the flight control software, 
 how many of you would disembark immediately?�

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

[Dan Cross]

In article <87zo9dug9p.fsf@pfaffben.user.msu.edu>,
Ben Pfaff  <pfaffben@msu.edu> wrote:
>That's a pretty hostile attitude to take in comp.lang.c.  Are you
>trolling?

Err, I'm a little surprised at this.  He's cross posting from comp.lang.ada,
but has been for quite some time.

	- Dan C.

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

[Ted Dennison]

In article <9kn116$sdc@augusta.math.psu.edu>, Dan Cross says...
>
>In article <87zo9dug9p.fsf@pfaffben.user.msu.edu>,
>Ben Pfaff  <pfaffben@msu.edu> wrote:
>>That's a pretty hostile attitude to take in comp.lang.c.  Are you
>>trolling?
>
>Err, I'm a little surprised at this.  He's cross posting from comp.lang.ada,
>but has been for quite some time.

Yeah. If you want to avoid reading trolls, perhaps it would be a good idea to
avoid threads crossposted to 4 newsgroups with over 200 messages in them. :-)

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

[Mark Wilden]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9mtjr3.bbs.randhol+abuse@kiuk0156.chembio.ntnu.no...
> 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.
>
> Your point was that speed was more important than the
> extra security. I don't agree.

Permit me to decide the point I'm trying to make. :)

Just to be crystal clear, I was saying nothing about speed vs. safety, nor
Ada vs. C++. I was just talking about 5%. In most applications, 5% is
meaningless. But in _some_ applications, it's important.

That's my point. Nothing else. OK? :)

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

[Preben Randhol]

On Mon, 6 Aug 2001 10:19:12 -0700, Mark Wilden wrote:
> Permit me to decide the point I'm trying to make. :)
> 
> Just to be crystal clear, I was saying nothing about speed vs. safety, nor
> Ada vs. C++. I was just talking about 5%. In most applications, 5% is
> meaningless. But in _some_ applications, it's important.

OK so then you can if you like turn off the checks to gain the speed you
want, if you know that your code is correct and that you won't waste
hours of calculations due to an error.

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

[James Rogers]

Chris Wolfe wrote:
> 
> 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?
> 

Be careful about such expansive statements. It is easy to read your
reply to imply that you can convert ANY Ada program to C++ without
overwhelming work. 

It is true that you can make such conversions for some Ada programs.
It is not true that all Ada programs can be converted to C++ wihtout
overwhelming work. 

Specifically, how would you code the C++ program to contain all the
checks built in by the Ada compiler, including the checks done at
compile time? How would you, without overwhelming work, convert
an Ada multi-tasking program using Ada protected objects for
asynchronous task communication, into C++?

For example, how would you, without overwhelming work, convert the
following Ada code:

-----------------------------------------------------------------------------
-- Inventory
-- Protected object for use of production lines
-----------------------------------------------------------------------------
   generic
   
   Max_Size : Positive;
   type Items is private;
   
   package Inventory is
   
      subtype Buf_Index is Positive range 1..Max_Size;
      type Parts_Buffer is array(Buf_Index) of Items;
   
      protected type Parts_Buf is
         Entry Put(Item : in Items);
         Entry Get(Item : out Items);
      private
         Buffer : Parts_Buffer;
         Oldest : Positive := 1;
         Newest : Positive := 1;
         Size   : Natural  := 0;
      end Parts_Buf;
   
      type Parts_Buf_Ptr is access Parts_Buf;
   
   end Inventory;


   package body Inventory is
   
   ---------------
   -- Parts_Buf --
   ---------------   
      protected body Parts_Buf is
      
      ---------
       -- Get --
      ---------
      
         entry Get (Item : out Items) when Size > 0 is
         begin
            Item := Buffer(Oldest);
            if Oldest < Buffer'Last then
               Oldest := Oldest + 1;
            else
               Oldest := Buffer'First;
            end if;
            Size := Size - 1;
         end Get;
      
      ---------
      -- Put --
      ---------
      
         entry Put (Item : in Items) when Size < Buffer'Last is
         begin
            Buffer(Newest) := Item;
            if Newest < Buffer'Last then
               Newest := Newest + 1;
            else
               Newest := Buffer'First;
            end if;
            Size := Size + 1;
         end Put;
      
      end Parts_Buf;
   end Inventory;

You will need to implement the full functionality of protected objects
including entry queuing, object locking, and boundary conditions.
You will also need to implement the integer range bounds limitations
created by the definition of the Positive subtype. It would be nice
if you could also define arrays with a beginning index of 1 rather
than 0, but you would probably assert that 0 based indexing is
equivalent to 1 based indexing. Curious, if it is equivalent, then
why can't C++ implement such an array directly?

Oh yes, when calling the Put and Get entries, your code must execute
in the calling thread. That thread must suspend until the entry
executes.
The entry may only execute when the boundary condition is true, and
no other entry is concurrently accessing the protected object.

You will have to implement the protected object as a template to be
equivalent. This means that you must find some way to specify that
one of the generic parameters is an integer greater than or equal to
1. If the parameter does not meet this requirement the code must not
compile. Putting the check in runtime code is not equivalent.

To make the code truly equivalent you must not define your data to 
be dynamically allocated. All items placed on the buffer must be
statically allocated.

Jim Rogers
Colorado Springs, Colorado USA

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

[Kaz Kylheku]

In article <3B6F5BB2.A879B933@worldnet.att.net>, James Rogers wrote:
>Specifically, how would you code the C++ program to contain all the
>checks built in by the Ada compiler, including the checks done at
>compile time? How would you, without overwhelming work, convert
>an Ada multi-tasking program using Ada protected objects for
>asynchronous task communication, into C++?

Since you don't have tasking in C++, you'd have to define some classes
for tasking and be prepared to port them. Or you could use an existing
framework for multitasking like ACE. Lastly, you could define your
implementaion language as being C++ plus POSIX, and use POSIX threads.
There are some portable POSIX threads implementations for non-POSIX
platforms, like Win32.

>For example, how would you, without overwhelming work, convert the
>following Ada code:

>-----------------------------------------------------------------------------
>-- Inventory
>-- Protected object for use of production lines
>-----------------------------------------------------------------------------
>   generic
>   
>   Max_Size : Positive;
>   type Items is private;
>   
>   package Inventory is
>   
>      subtype Buf_Index is Positive range 1..Max_Size;
>      type Parts_Buffer is array(Buf_Index) of Items;
>   
>      protected type Parts_Buf is
>         Entry Put(Item : in Items);
>         Entry Get(Item : out Items);
>      private
>         Buffer : Parts_Buffer;
>         Oldest : Positive := 1;
>         Newest : Positive := 1;
>         Size   : Natural  := 0;
>      end Parts_Buf;
>   
>      type Parts_Buf_Ptr is access Parts_Buf;
>   
>   end Inventory;
>
>
>   package body Inventory is
>   
>   ---------------
>   -- Parts_Buf --
>   ---------------   
>      protected body Parts_Buf is
>      
>      ---------
>       -- Get --
>      ---------
>      
>         entry Get (Item : out Items) when Size > 0 is
>         begin
>            Item := Buffer(Oldest);
>            if Oldest < Buffer'Last then
>               Oldest := Oldest + 1;
>            else
>               Oldest := Buffer'First;
>            end if;
>            Size := Size - 1;
>         end Get;
>      
>      ---------
>      -- Put --
>      ---------
>      
>         entry Put (Item : in Items) when Size < Buffer'Last is
>         begin
>            Buffer(Newest) := Item;
>            if Newest < Buffer'Last then
>               Newest := Newest + 1;
>            else
>               Newest := Buffer'First;
>            end if;
>            Size := Size + 1;
>         end Put;
>      
>      end Parts_Buf;
>   end Inventory;
>
>You will need to implement the full functionality of protected objects
>including entry queuing, object locking, and boundary conditions.

Not really. I just need some class representing a mutex and conditoin
variable, call them Mutex and Condition. Let's assume I have these
classes.

#include <stddef.h>	// for size_t

namespace Inventory {
	template <typename Item, size_t BufferSize> class PartsBuffer {
	private:
		Item itemBuf[BufferSize];
		size_t oldestItem;
		size_t newestItem;
		size_t numItemsInBuffer;
		Mutex mutex;		// not standard C++, ah well
		Condition cond;
	private:
		bool BufferIsFull() { numItemsInBuffer == BufferSize; }
		bool BufferIsEmpty() { numItemsInBuffer == 0; }
	public:
		PartsBuffer() 
		: oldestItem(0)
		, newestItem(0)
		, numItemsInBuffer(0) { }

		void Put(Item it)
		{
			mutex.Lock();
			while (BufferIsFull())
				mutex.Wait(&cond);
			itemBuf[newestItem] = it;
			newestItem = (newestItem + 1) % BufferSize;
			numItemsInBuffer++;
			mutex.Unlock();
			cond.Broadcast();
		}

		Item Get()
		{
			mutex.Lock();
			while (BufferIsEmpty())
				mutex.Wait(&cond);
			Item returnedItem = itemBuf[oldestItem];
			oldestItem = (oldestItem + 1) % BufferSize;
			numItemsInBuffer--;
			mutex.Unlock();
			cond.Broadcast();
			return returnedItem;
		}
	};
}

>if you could also define arrays with a beginning index of 1 rather
>than 0, but you would probably assert that 0 based indexing is

What advantage is there in indexing a buffer starting at 1?  A circular
buffer is hardly a data structure that requires 1 based arrays.
There is no significance to the absolute value of the array index
of a circular buffer, that's why it's called circular.

>Oh yes, when calling the Put and Get entries, your code must execute
>in the calling thread. That thread must suspend until the entry
>executes.
>
>The entry may only execute when the boundary condition is true, and
>no other entry is concurrently accessing the protected object.

All done by the mutex and condition waits.

>You will have to implement the protected object as a template to be
>equivalent. This means that you must find some way to specify that
>one of the generic parameters is an integer greater than or equal to
>1. If the parameter does not meet this requirement the code must not
>compile. Putting the check in runtime code is not equivalent.

In the C++ code, this translates to a need to verify that the BufferSize
template parameter is greater than zero.  The constraint on array
declarations will take care of this for me: If the parameter is zero
or negative, the array will be declared as having zero or negative
elements. (The parameter can't be negative because it's an unsigned type,
size_t).

(In general, you can write a compile_time_assert() macro which exploits
array constraint checks in order to verify some predicate over a constant
expression.  I learned this trick from Chris Torek of BSDi, Inc).

>To make the code truly equivalent you must not define your data to 
>be dynamically allocated. All items placed on the buffer must be
>statically allocated.

Done: it's a simple low-level array that's integrated into the objects. No
std::vector or similar braindamage.

It doesn't have range checks, but then the array indices are under
control of the class, and can be verified to be correct, and the *user*
of the class can't cause any harm using Put/Get, which are the only
public functions other than the constructor. The purpose of this
class is to provide a safe ring buffer; we have built a safe thing out
of some unsafe elements.

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

[James Rogers]

Kaz Kylheku wrote:
> 
> >Oh yes, when calling the Put and Get entries, your code must execute
> >in the calling thread. That thread must suspend until the entry
> >executes.
> >
> >The entry may only execute when the boundary condition is true, and
> >no other entry is concurrently accessing the protected object.
> 
> All done by the mutex and condition waits.

Not quite. A mutex and condition waits do not provide a queue
for the waiting tasks. This queue must provide orderly access
to the protected object when the condition allows. If you have
functions associated with the protected object (i.e. read only
functions) then you must allow multiple threads to access the
object through those functions simultaneously, without mutex
locking. At the same time, the entries (functions that update
the object) must be blocked by the mutex so that they are 
prevented from simultaneous access, even when the read only
functions are accessing the object. The read only functions
must be blocked from accessing the object when an update
function is accessing the object.

What will you do when your platform does not support POSIX threads?
You will have to recode the non-conforming parts (in a POSIX sense)
to use the local platform's approach. This appears to add a
significant effort in design, coding, testing, and system documentation.
It also adds complexity in configuration management.

> >You will have to implement the protected object as a template to be
> >equivalent. This means that you must find some way to specify that
> >one of the generic parameters is an integer greater than or equal to
> >1. If the parameter does not meet this requirement the code must not
> >compile. Putting the check in runtime code is not equivalent.
> 
> In the C++ code, this translates to a need to verify that the BufferSize
> template parameter is greater than zero.  The constraint on array
> declarations will take care of this for me: If the parameter is zero
> or negative, the array will be declared as having zero or negative
> elements. (The parameter can't be negative because it's an unsigned type,
> size_t).

So this means that you must wait until run time to perform the checking.
It also means that you allow the system to create a useless, zero
size communication object. Neither of these options thrill me. Calls
to a zero size object should always fail because the object is 
simultaneously both full and empty all the time. Checking the parameter
at run time means that I must be satisfied with having to wait until
run time to find out if the parameter is correct. This check may need
to be made many times in the system, assuming the system creates many
instances of the template object. Therefore, fixing the problem may
take several iterations, where a simple compiler check will find all
the problems at once.

> (In general, you can write a compile_time_assert() macro which exploits
> array constraint checks in order to verify some predicate over a constant
> expression.  I learned this trick from Chris Torek of BSDi, Inc).

Interesting. Does this mean that there is only one such macro in
your system, providing only one size of circular buffer? If so, it
seems to limit the usefulness of defining the buffer in a template.

> 
> >To make the code truly equivalent you must not define your data to
> >be dynamically allocated. All items placed on the buffer must be
> >statically allocated.
> 
> Done: it's a simple low-level array that's integrated into the objects. No
> std::vector or similar braindamage.

I think you misunderstood my point here. The data placed on the
C++ version of a protected object must not be dynamically allocated.
I assumed the buffer itself would be implemented in a primitive C
style array for efficiency purposes.

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

[Kaz Kylheku]

In article <3B7078C3.60194D58@worldnet.att.net>, James Rogers wrote:
>> >The entry may only execute when the boundary condition is true, and
>> >no other entry is concurrently accessing the protected object.
>> 
>> All done by the mutex and condition waits.
>
>Not quite. A mutex and condition waits do not provide a queue
>for the waiting tasks.  This queue must provide orderly access
>to the protected object when the condition allows. If you have
>functions associated with the protected object (i.e. read only
>functions) then you must allow multiple threads to access the
>object through those functions simultaneously, without mutex
>locking. At the same time, the entries (functions that update
>the object) must be blocked by the mutex so that they are 
>prevented from simultaneous access, even when the read only
>functions are accessing the object. The read only functions
>must be blocked from accessing the object when an update
>function is accessing the object.

So you have a read/write lock with condition variables? I have implemented
something exactly like that: a read-write lock in which one can atomically
give up a read or write lock to wait on a condition. 

>What will you do when your platform does not support POSIX threads?

Port them. The C++ code that I maintain professionally uses monitors
and conditions, and read-write locks. The clases work on Win32, POSIX
and PalmOS.  I can make them work anywhere.  I made them from scratch;
they do not simply delegate to POSIX mutexes and conditions.  And in
fact they were initially developed under Win32. The POSIX and PalmOS
ports came out of the blue; they were nowhere on the ``radar'' when
the stuff was initially developed.

>You will have to recode the non-conforming parts (in a POSIX sense)
>to use the local platform's approach. This appears to add a
>significant effort in design, coding, testing, and system documentation.
>It also adds complexity in configuration management.

I understand the point that Ada has built-in standard tasks and
synchronization. Standard things are nice, if they exist for every
target platform.

>> template parameter is greater than zero.  The constraint on array
>> declarations will take care of this for me: If the parameter is zero
>> or negative, the array will be declared as having zero or negative
>> elements. (The parameter can't be negative because it's an unsigned type,
>> size_t).
>
>So this means that you must wait until run time to perform the checking.

No, the constraint violation on the array declaration is a translation
time check.

>It also means that you allow the system to create a useless, zero
>size communication object.

No. You can't declare a zero-sized array in ANSI C++. That is a diagnosable
semantic rule violation.

>> (In general, you can write a compile_time_assert() macro which exploits
>> array constraint checks in order to verify some predicate over a constant
>> expression.  I learned this trick from Chris Torek of BSDi, Inc).
>
>Interesting. Does this mean that there is only one such macro in
>your system, providing only one size of circular buffer? If so, it
>seems to limit the usefulness of defining the buffer in a template.

No, the macro takes an arbitrary expression. If that expression is zero,
it turns it into some diagnosable constraint rule violation.
For instance:

	#define compile_assert(EXPR) { int array[-1+2*(int)((EXPR)!=0)]; }

If the expression is non-zero/true, then an array of 1 element is
declared.  If it is zero, then an array of -1 elements is declared,
triggering a constraint violation.

This could be written into the body of a member function of a parametrized
class:

	template <int foo_param> foo_class::frob()
	{
		compile_assert (foo_param >= 42 && foo_param < 255);
	}

Thus attempted instantiations of the template over foo_param outside of
the specified range will cause a diagnostic.

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

[Ted Dennison]

In article <iG%b7.29321$B37.591139@news1.rdc1.bc.home.com>, Kaz Kylheku says...
>
>>What will you do when your platform does not support POSIX threads?
>
>Port them. The C++ code that I maintain professionally uses monitors

Have fun porting them to DOS. :-)

Wouldn't it be better if someone had already done all that work for you, and
debugged it? That's what you get with Ada.

>I understand the point that Ada has built-in standard tasks and
>synchronization. Standard things are nice, if they exist for every
>target platform.

:-)
You seem to have a peculiar view of the word "standard". It probably comes from
being in the C world, where a "standard" is often considered no better than a
suggestion or a guideline. 

"Standard" for Ada means that *every* compiler has it, no matter what the
platform. There is an exhaustive test suite that compilers must run through to
be considered true Ada compilers, and it includes tests for tasking support, and
tasking behavior. DOS Ada compilers have tasking. Bare M68K Ada compilers have
tasking. Ada compilers for OS's with heavy processes but no threads have
tasking. And in all of these cases, you can count on the tasking working as per
the Ada LRM (at least up to the annexes).

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

[Kaz Kylheku]

In article <3B6F5BB2.A879B933@worldnet.att.net>, James Rogers wrote:
>   generic
>   
>   Max_Size : Positive;
>   type Items is private;
>   
>   package Inventory is
>   
>      subtype Buf_Index is Positive range 1..Max_Size;
>      type Parts_Buffer is array(Buf_Index) of Items;

By the way, is there a reason why you didn't just use a modulo
type as the array index, one that will automatically wrap around
1..Max_Size-1?

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

[James Rogers]

Kaz Kylheku wrote:
> 
> In article <3B6F5BB2.A879B933@worldnet.att.net>, James Rogers wrote:
> >   generic
> >
> >   Max_Size : Positive;
> >   type Items is private;
> >
> >   package Inventory is
> >
> >      subtype Buf_Index is Positive range 1..Max_Size;
> >      type Parts_Buffer is array(Buf_Index) of Items;
> 
> By the way, is there a reason why you didn't just use a modulo
> type as the array index, one that will automatically wrap around
> 1..Max_Size-1?

No. Just simple foolishness. I simply got out of the habit of
starting my counting with 0.

Jim Rogers
Colorado Springs, Colorado USA

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

[Daniel Fischer]

Hi,

- followup ("James Rogers" <jimmaureenrogers@worldnet.att.net>)

> For example, how would you, without overwhelming work, convert the
> following Ada code:
> [snip code]

I have no idea.

In fact I have no idea what your code does in the first place. And that's
your very problem; C programmers don't get Algol-like code by definition,
so please design a language with more curly brackets before you Ada people
crosspost Ada advocacy to comp.lang.c again.

This is nothing personal. It's just that I don't think a thread about the
pros and cons of Ada crossposted to cl.c and cl.c++ was such a good idea.


Daniel

-- 
IMO, anyway.
end  message by (Daniel Fischer <dan@gueldenland.de>)
clc FAQ:    http://www.eskimo.com/~scs/C-faq/top.html
08/07	Battle of Boyaca in Colombia

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

[Chris Wolfe]

James Rogers wrote:
> 
> Chris Wolfe wrote:
> >
> > It does not require any overwhelming work to convert an Ada
> > program directly into a functionally identical C++ program using
> > appropriate (non-standard) templates.
> 
> Be careful about such expansive statements. It is easy to read your
> reply to imply that you can convert ANY Ada program to C++ without
> overwhelming work.

That *was* my statement.

> Specifically, how would you code the C++ program to contain all the
> checks built in by the Ada compiler, including the checks done at
> compile time?

Most likely using templates and the type-safety system included
in C++. There are a few (like the assignment of a <= 0 value to
Positive) that would be trivial to optimize in any case ("Error:
This call will always cause precondition Foo in Bar to fail.");

> How would you, without overwhelming work, convert
> an Ada multi-tasking program using Ada protected objects for
> asynchronous task communication, into C++?

Unless I've completely forgotten my Ada...

// If not declared here, in the library.

template <Positive Max_Size, class Item>
class Inventory
{

typedef Integer<1, Max_Size> Buf_Index;

// one-based array of Items with Buf_Index elements
typedef BasedArray<1, Buf_Index, Items> Parts_Buffer;

class Parts_Buf
{
  public:
    void Put(const Array<Item> &item)
    {
      Access::Ptr ptr = Parts_Buf_Ptr.Lock();
      if (Size >= Buffer.Last) throw IllegalArgumentException;

      Item = Buffer[Oldest];
      if (Oldest < Buffer.Last) {
        Oldest++;
      }
      else {
        Oldest = Buffer.First;
      }

      Size--;
    }

    void Get(Array<Item> &item)
    {
      Access::Ptr ptr = Parts_Buf_Ptr.Lock();
      if (Size <= 0) throw InvalidArgumentException;
      // ...
    }

  private:
    Access Parts_Buf_Ptr;
    Parts_Buffer Buffer;
    Positive Oldest = 1;
    Positive Newest = 1;
    Natural  Size = 0;
};
};

> You will need to implement the full functionality of protected objects
> including entry queuing, object locking

Stock utils lib.

> , and boundary conditions.

Checked manually for parameters. I forget which compiler
supported external expression lists for pre- and post-conditions
(and did allow you to leave them active at run-time).

> You will also need to implement the integer range bounds limitations
> created by the definition of the Positive subtype.


Positive(int v) { assert(v > 0); ... }

> It would be nice
> if you could also define arrays with a beginning index of 1 rather
> than 0, but you would probably assert that 0 based indexing is
> equivalent to 1 based indexing. Curious, if it is equivalent, then
> why can't C++ implement such an array directly?

Stock utils lib. A lot of C++ provides things that are difficult
for a human to implement by hand, and ignores things that are as
trivial as array[i - 1].

> Oh yes, when calling the Put and Get entries, your code must execute
> in the calling thread. That thread must suspend until the entry
> executes.

Stock utils lib. I remember seeing
blocks-in-which-methods-protected-by-lock somewhere, and it is
trivial to add.

> The entry may only execute when the boundary condition is true, and
> no other entry is concurrently accessing the protected object.

And when boundary condition is false? I'm assuming a runtime
error of some sort, unless the wait is clearly documented.

> You will have to implement the protected object as a template to be
> equivalent. This means that you must find some way to specify that
> one of the generic parameters is an integer greater than or equal to
> 1.

I think that's possible if the compiler is smart enough to
optimize the static cast from int to Positive. If not, it's an
optimization that could easily be added, as it is pretty trivial
to discover that Positive's cast constructor will always fail for
values <= 0 (especially with explicit preconditions, which I have
also encountered).

> If the parameter does not meet this requirement the code must not
> compile. Putting the check in runtime code is not equivalent.
>
> To make the code truly equivalent you must not define your data to
> be dynamically allocated. All items placed on the buffer must be
> statically allocated.

Stock utils lib.

So you are sort of correct, there are some features of Ada that
would require minor changes to the 'default' C++ compiler
behaviors to provide with the same level of hand-holding provided
by Ada. I have already encountered compilers that do most of
these, and I would bet that the rest have been implemented
somewhere.

Chris

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

[Chris Wolfe]

Chris Wolfe wrote:
> 
> James Rogers wrote:
[snip]
> > The entry may only execute when the boundary condition is true, and
> > no other entry is concurrently accessing the protected object.
> 
> And when boundary condition is false? I'm assuming a runtime
> error of some sort, unless the wait is clearly documented.

Fixing the parameter, and adding a safe wait:

void Put(const Item &item)
{
  Access::Ptr ptr = Parts_Buf_Ptr.Enqueue();
  while (Size >= Buffer.Last) ptr.Wait();
  
  // etc...
}

void Get(Item &item)
{
  Access::Ptr ptr = Parts_Buf_Ptr.Enqueue();
  while (Size < 0) ptr.Wait();
  
  // etc...
}

Chris

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

[James Rogers]

Chris Wolfe wrote:
> 
> So you are sort of correct, there are some features of Ada that
> would require minor changes to the 'default' C++ compiler
> behaviors to provide with the same level of hand-holding provided
> by Ada. I have already encountered compilers that do most of
> these, and I would bet that the rest have been implemented
> somewhere.

And none of these extensions are actually standard C++. They are not
part of the standard or the standard libraries. This means that you
will need to re-implement them if you are forced to switch to another
compiler because you are porting your code to another system.

Note that I never claimed that C++ could not produce equivalent 
code. I merely stated that I thought it would require a lot more
work, what you called "overwhelming effort". 

Your solutions appear to require the creation of a number of classes
such as Positive, and your Parts_Buf. Of course, the Parts_Buf class 
you defined does not begin to implement a protected object, only
a circular buffer. 

The answer "Stock utils lib." is a little vague for me. Which lib
provides the full capabilities of an Ada protected object,
including entry queuing, exclusive update access with multiple
read only access? Which lib provides the same for all common OS
combinations supporting threads, so that recoding is not needed
as part of the porting effort?

Your example and explanation clearly convinces me that the C++
effort to produce an equivalent to an Ada protected object
would require a significant effort. This is not an argument
against C++. This is merely an set of capabilities not yet
implemented as part of the C++ standard. Achieving similar
capabilities is difficult in most languages.

Jim Rogers
Colorado Springs, Colorado USA

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

[Kaz Kylheku]

In article <3B70C621.DC9A8F35@worldnet.att.net>, James Rogers wrote:
>Chris Wolfe wrote:
>> 
>> So you are sort of correct, there are some features of Ada that
>> would require minor changes to the 'default' C++ compiler
>> behaviors to provide with the same level of hand-holding provided
>> by Ada. I have already encountered compilers that do most of
>> these, and I would bet that the rest have been implemented
>> somewhere.
>
>And none of these extensions are actually standard C++. They are not
>part of the standard or the standard libraries.

If some platform was only targetted by an Ada compiler that was missing
some diagnostic features, would take the high road, and not compile
your programs for that platform, even if the compiler could translate
and execute correct Ada programs?

>This means that you
>will need to re-implement them if you are forced to switch to another
>compiler because you are porting your code to another system.

Or you just leave the code the same and lose the diagnostic capabilities.
You can still use the other compiler for diagnosing the code.  You don't
lose anything by porting.

>Your example and explanation clearly convinces me that the C++
>effort to produce an equivalent to an Ada protected object
>would require a significant effort.

Standard Ada has multitasking built in, and standard C++ other doesn't.
So writing a protected object does not require signficant effort in
standard C++, but is simply impossible.

>This is not an argument
>against C++. This is merely an set of capabilities not yet
>implemented as part of the C++ standard. Achieving similar
>capabilities is difficult in most languages.

Achieving things in languages is sometimes just paperwork. It wouldn't
take much to define some standard C++ library for multithreading. The
difficulty lies in implementations.

If you add difficult things into languages, two things happen.
They get implemented less, or sometimes they get implemented
incompletely.

We see this with C++: poor support for templates here and there, lack of
support for exception handling here and there. 

Some things should be left to the open market, at least for a while.
C++ was only standardized in 1998 for the first time. Thus far,
there hasn't emerged a *de facto* standard library for multithreading
that could serve as a candidate for becoming standard. So the
C++ committee will perhaps have to invent one, (assuming they want to 
add multithreading).

The problem with multithreading is that there are so many ways to hack it
on a given platform. If you have standard threading, but C++
implementors cop out with lame implementations, nobody will want to
use it.  Or they will use it, but programs will only work well on a few
quality implementations, in essence rendering the standard threading
portable only on paper. 

Any decent C++ threading will have to interoperate nicely with a
platform's ``native'' threading, because real-world C++ programs are
rarely developed in a vacuum. People will do things like create threads
using some platform-specific mechanism, and have it execute parts of
the C++ program along side C++ threads --- kind of hard to avoid,
for instance, if using some third party library which wants to invoke
callbacks in your program, using its own threads.

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

[Kaz Kylheku]

In article <3B70C621.DC9A8F35@worldnet.att.net>, James Rogers wrote:
>Chris Wolfe wrote:
>> 
>> So you are sort of correct, there are some features of Ada that
>> would require minor changes to the 'default' C++ compiler
>> behaviors to provide with the same level of hand-holding provided
>> by Ada. I have already encountered compilers that do most of
>> these, and I would bet that the rest have been implemented
>> somewhere.
>
>And none of these extensions are actually standard C++. They are not
>part of the standard or the standard libraries.

If some platform was only targetted by an Ada compiler that was missing
some diagnostic features, would take the high road, and not compile
your programs for that platform, even if the compiler could translate
and execute correct Ada programs?

>This means that you
>will need to re-implement them if you are forced to switch to another
>compiler because you are porting your code to another system.

Or you just leave the code the same and lose the diagnostic capabilities.
You can still use the other compiler for diagnosing the code.  You don't
lose anything by porting.

>Your example and explanation clearly convinces me that the C++
>effort to produce an equivalent to an Ada protected object
>would require a significant effort.

Standard Ada has multitasking built in, and standard C++ other doesn't.
So writing a protected object does not require signficant effort in
standard C++, but is simply impossible.

>This is not an argument
>against C++. This is merely an set of capabilities not yet
>implemented as part of the C++ standard. Achieving similar
>capabilities is difficult in most languages.

Achieving things in languages is sometimes just paperwork. It wouldn't
take much to define some standard C++ library for multithreading. The
difficulty lies in implementations.

If you add difficult things into languages, two things happen.
They get implemented less, or sometimes they get implemented
incompletely.

We see this with C++: poor support for templates here and there, lack of
support for exception handling here and there. 

Some things should be left to the open market, at least for a while.
C++ was only standardized in 1998 for the first time. Thus far,
there hasn't emerged a *de facto* standard library for multithreading
that could serve as a candidate for becoming standard. So the
C++ committee will perhaps have to invent one, (assuming they want to 
add multithreading).

The problem with multithreading is that there are so many ways to hack it
on a given platform. If you have standard threading, but C++
implementors cop out with lame implementations, nobody will want to
use it.  Or they will use it, but programs will only work well on a few
quality implementations, in essence rendering the standard threading
portable only on paper. 

Any decent C++ threading will have to interoperate nicely with a
platform's ``native'' threading, because real-world C++ programs are
rarely developed in a vacuum. People will do things like create threads
using some platform-specific mechanism, and have it execute parts of
the C++ program along side C++ threads --- kind of hard to avoid,
for instance, if using some third party library which wants to invoke
callbacks in your program, using its own threads.

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

[James Rogers]

Kaz Kylheku wrote:
> 
> Achieving things in languages is sometimes just paperwork. It wouldn't
> take much to define some standard C++ library for multithreading. The
> difficulty lies in implementations.
> 
> If you add difficult things into languages, two things happen.
> They get implemented less, or sometimes they get implemented
> incompletely.
> 
> We see this with C++: poor support for templates here and there, lack of
> support for exception handling here and there.

Ada has gone through two standardizations (1983 and 1995). 
Concurrency has been in the language since the first standard.
The new standard did add capabilities to the Ada concurrency model,
fixing a tendency towards race conditions, and adding a cleaner
approach to asynchronous communications. 

Ada has also had generics and exceptions since the first standard.
Every Ada compiler in the market place implements all these features.

This does not mean that the features are easier in Ada. It might
mean that the Ada standard is better written than the C++ standard.
I cannot testify to that issue, not being a compiler writer myself.

> Some things should be left to the open market, at least for a while.
> C++ was only standardized in 1998 for the first time. Thus far,
> there hasn't emerged a *de facto* standard library for multithreading
> that could serve as a candidate for becoming standard. So the
> C++ committee will perhaps have to invent one, (assuming they want to
> add multithreading).

Standardization is a very formal process. New features may be
influenced by the open market. On the other hand, they are also
often influenced by careful research and a clearly stated set of
requirements.

Market forces are not always as clear as some would like to believe.
For instance, are the Microsoft tools driven by the market, or do
they drive the market? Comments by others in this thread seem to
indicate they drive at least a large portion of the market. Allowing
language features to be "driven by the open market" seems to be
nothing more than letting the dominant players control the language.
Sometimes this may be good. Other times it clearly is not.

> The problem with multithreading is that there are so many ways to hack it
> on a given platform. If you have standard threading, but C++
> implementors cop out with lame implementations, nobody will want to
> use it.  Or they will use it, but programs will only work well on a few
> quality implementations, in essence rendering the standard threading
> portable only on paper.

The same argument could be made about programming in general.
There are so many ways to hack it on a given platform. If you
standardize a language implementers will cop out with lame
implementations nobody will want to use. Is this your experience
with C++ since standardization? I hope not.

> Any decent C++ threading will have to interoperate nicely with a
> platform's ``native'' threading, because real-world C++ programs are
> rarely developed in a vacuum. People will do things like create threads
> using some platform-specific mechanism, and have it execute parts of
> the C++ program along side C++ threads --- kind of hard to avoid,
> for instance, if using some third party library which wants to invoke
> callbacks in your program, using its own threads.

Just as any decent C++ implementation will have to interoperate nicely
with a platform's other "native" operating system features. There is no
reason to isolate threading as a special case.

Jim Rogers
Colorado Springs, Colorado USA

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

[Ted Dennison]

In article <yd4c7.29954$B37.620460@news1.rdc1.bc.home.com>, Kaz Kylheku says...
>
>In article <3B70C621.DC9A8F35@worldnet.att.net>, James Rogers wrote:
>>And none of these extensions are actually standard C++. They are not
>>part of the standard or the standard libraries.
>
>If some platform was only targetted by an Ada compiler that was missing
>some diagnostic features, would take the high road, and not compile
>your programs for that platform, even if the compiler could translate
>and execute correct Ada programs?

I can't answer for James, but I can tell you that few (if any) Ada compilers
currently behave that way precisely because the Ada community as a *whole* does
not accept compilers that do not adhere to the spec. In particular, there is a
validation procedure that must be followed, which includes very extensive
testing of the compiler against a large test suite designed to exercise as much
of the Ada spec as possible. Many Ada users demand to see the conformance
certificate before considering purchase of a compiler. I can't give you a good
percentage of users that feel this way, but apparently it has been enough to
discourage non-conformant compilers. 

Interestingly, I had heard (consider it a rumor, if you will) that at least one
of these agencies has also developed conformance tests for C++, but not a single
vendor has ever asked to use them. :-)


>If you add difficult things into languages, two things happen.
>They get implemented less, or sometimes they get implemented
>incompletely.

I'd say the experience of Ada's Distributed Programming annex bears this out. 

>We see this with C++: poor support for templates here and there, lack of
>support for exception handling here and there. 

Apparently the bar for "difficult" in C++ is set a *lot* lower. :-)

I'd just say that C++ community doesn't care nearly as much about portability as
the Ada community (or perhaps they are more accustomed to not getting it).

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

[Ole-Hjalmar Kristensen]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> Chris Wolfe wrote:
> > 
> > So you are sort of correct, there are some features of Ada that
> > would require minor changes to the 'default' C++ compiler
> > behaviors to provide with the same level of hand-holding provided
> > by Ada. I have already encountered compilers that do most of
> > these, and I would bet that the rest have been implemented
> > somewhere.
> 
> And none of these extensions are actually standard C++. They are not
> part of the standard or the standard libraries. This means that you
> will need to re-implement them if you are forced to switch to another
> compiler because you are porting your code to another system.
> 
> Note that I never claimed that C++ could not produce equivalent 
> code. I merely stated that I thought it would require a lot more
> work, what you called "overwhelming effort". 
> 
> Your solutions appear to require the creation of a number of classes
> such as Positive, and your Parts_Buf. Of course, the Parts_Buf class 
> you defined does not begin to implement a protected object, only
> a circular buffer. 
> 
> The answer "Stock utils lib." is a little vague for me. Which lib
> provides the full capabilities of an Ada protected object,
> including entry queuing, exclusive update access with multiple
> read only access? Which lib provides the same for all common OS
> combinations supporting threads, so that recoding is not needed
> as part of the porting effort?

If you stick to Posix threads, you get what you need, although it's
not an exact match with the Ada tasking features.
However, in my experience, Posix works better with C than C++, we have
been bitten by some really weird bugs related to destructors,
statically allocated objects an semaphores.
When it comes to tasking, Ada wins hands down if you compare it to
C/C++/Posix.

> 
> Your example and explanation clearly convinces me that the C++
> effort to produce an equivalent to an Ada protected object
> would require a significant effort. This is not an argument
> against C++. This is merely an set of capabilities not yet
> implemented as part of the C++ standard. Achieving similar
> capabilities is difficult in most languages.
> 
> Jim Rogers
> Colorado Springs, Colorado USA

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

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

[Chris Wolfe]

James Rogers wrote:
[snip]
> Your example and explanation clearly convinces me that the C++
> effort to produce an equivalent to an Ada protected object
> would require a significant effort. This is not an argument
> against C++. This is merely an set of capabilities not yet
> implemented as part of the C++ standard. Achieving similar
> capabilities is difficult in most languages.

Sorry, I assumed you caught the "using appropriate (non-standard)
templates" clause (more accurately it would have been: templates,
classes, and functions).

Comparing the standard libraries in most languages with a
language and library designed specifically for safe use would be
pretty stupid. The "stock utils lib" is the library of stuff that
I ported from Ada when I originally moved to C++ (my standard,
not the world's).

My big reason for using C-like languages at the moment is the
lack of verbosity. Now if only I could get Haskell-like syntax in
a procedural language...

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.

[Kaz Kylheku]

In article <3B70BDA5.575D8E6A@home.com>, 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?  Does it throw an exception when your integer or unsigned
>type overflows? I expect not. 

Note that unsigned types cannot overflow in C++, by definition.

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

The bounds checking GCC patches work well, but only support the C front
end (last time I checked). The checking is also not perfect.  It's done on
object granularity, not sub-object granularity.  Say an array is embedded
in a struct and is not the first member, An overrun of that array can
clobber other members; bounds checking GCC will not detect that. It knows
that an object of a certain size is being manipulated, namely the entire
struct.  Anything that is dynamically allocated via a single malloc() call
is also just a single object: essentially a character array that wide.
I think that this is about the best you can do without doing a lot
more work. And it's certainly better than no checking at all!
Even protecting primary objects traps nasty classes of errors whereby
a problem in one module causes strange failures in another.

Bounds checking GCC works with the help of a run-time library, which
keeps track of all live objects in a splay tree data structure.
A pointer can be used as a key to locate a node within the tree,
which provides the attributes of the object that the pointer points
to. So the pointer representation is not changed in any way, preserving
binary compatibility with existing code (except that two pointer bit
patterns are reserved for representing special values).

To my recollection, the run-time library is not thread safe. Also,
programs that use longjmp() causes problems, because it won't be 
noted that certain automatic objects no longer exist. (The tracking
of automatic objects is keyed to the same mechanism that is used
for C++ constructors and destructors in the GCC back end, and
longjmp() doesn't play nicely with that).

On the plus side, Bounds Checking GCC does nice things with pointer
arithmetic. A bad pointer doesn't have to be dereferenced to be diagnosed,
merely calculated, so that for instance p = malloc(10) + 11 can be
flagged as an error.

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

[Warren W. Gay VE3WWG]

Kaz Kylheku wrote:
> In article <3B70BDA5.575D8E6A@home.com>, 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?  Does it throw an exception when your integer or unsigned
> >type overflows? I expect not.
> 
> Note that unsigned types cannot overflow in C++, by definition.

Fair enough. Modular types in Ada don't "overflow" either - they
wrap around as in C. However, modular types in Ada wrap around
according to the declared modularity. Unsigned types in C only 
have one implementation defined modularity, according to their size.

> >> 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.
> 
> The bounds checking GCC patches work well, but only support the C front
> end (last time I checked). The checking is also not perfect.  It's done on
> object granularity, not sub-object granularity.  Say an array is embedded
> in a struct and is not the first member, An overrun of that array can
> clobber other members; bounds checking GCC will not detect that. It knows
> that an object of a certain size is being manipulated, namely the entire
> struct.  

I can see this as useful for detecting gross errors, but all too many
array bounds errors are more subtle that that. They usually are one-offs,
or in some cases a few-offs... but overwriting the full extent of the
class/structure occurs left often, perhaps.

> Anything that is dynamically allocated via a single malloc() call
> is also just a single object: essentially a character array that wide.
> I think that this is about the best you can do without doing a lot
> more work. And it's certainly better than no checking at all!

Agreed.

> Even protecting primary objects traps nasty classes of errors whereby
> a problem in one module causes strange failures in another.

Sometimes. At work, I've spent too much time trying to find more
subtle problems like somebody's ancient code has corrupted the
heap that causes the free() call to fail. Malloc's linked list
has probably been stepped on early in the program, but only when
all of the structure elements are being freed does this problem rear 
it's ugly head. 

But agreed, any help is welcome.

> Bounds checking GCC works with the help of a run-time library, which
> keeps track of all live objects in a splay tree data structure.
> A pointer can be used as a key to locate a node within the tree,
> which provides the attributes of the object that the pointer points
> to. So the pointer representation is not changed in any way, preserving
> binary compatibility with existing code (except that two pointer bit
> patterns are reserved for representing special values).

While this is useful for debugging purposes, it is by no means a good
production mode to use. The _cost_ of looking up each pointer would
be enormous by comparison to the compiled in code that Ada provides
(no lookups necessary). And of course, the Ada checks can be compiled 
out at some point too, if that be "the wish of the master".

> To my recollection, the run-time library is not thread safe. Also,
> programs that use longjmp() causes problems, because it won't be
> noted that certain automatic objects no longer exist. (The tracking
> of automatic objects is keyed to the same mechanism that is used
> for C++ constructors and destructors in the GCC back end, and
> longjmp() doesn't play nicely with that).

Thank you for the clarification on the GCC front. This certainly
gives us all the clear picture of where the compiler stands in
comparison to Ada on these "safety" points.

> On the plus side, Bounds Checking GCC does nice things with pointer
> arithmetic. A bad pointer doesn't have to be dereferenced to be diagnosed,
> merely calculated, so that for instance p = malloc(10) + 11 can be
> flagged as an error.

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

[Ed Falis]

Chris Wolfe wrote:
> 
> 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.

Taking this statement out of context (given that I think your philosophy
expressed in the rest of the message is quite sound), I still have to
correct it.

Most Ada compilers provide inline assembly language as well - it's part
of the language standard.  The only philosophical difference (I think)
is safety by default vs safety by proactivity.  As far as I can tell
after a lot years working with it, there is no Ada thing oriented
towards throwing away flexibility, nor towards force.  But I've been
known to be wrong - that's how I learn.

- Ed

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

[Chris Wolfe]

Ed Falis wrote:
> Chris Wolfe wrote:
> >
> > 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.
> 
> Taking this statement out of context (given that I think your philosophy
> expressed in the rest of the message is quite sound), I still have to
> correct it.
> 
> Most Ada compilers provide inline assembly language as well - it's part
> of the language standard.  The only philosophical difference (I think)
> is safety by default vs safety by proactivity.  As far as I can tell
> after a lot years working with it, there is no Ada thing oriented
> towards throwing away flexibility, nor towards force.  But I've been
> known to be wrong - that's how I learn.

Yes, I missed the assembler entry entirely. So much for my
"difference" between Ada and C++... You folks *are* useful ;)

Now if only I could find the rest of the Ada libraries ported to
C++. I got attached to concise syntax very quickly. (Yes, before
anyone asks, I want to find Haskell-like brace/semicolon rules in
a C++ preprocessor)

Cheers,
Chris

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

[Ed Falis]

Chris Wolfe wrote:
> 
> Ed Falis wrote:
> > Chris Wolfe wrote:
> > >
> > > So we do the Ada thing: throw away the flexibility of the

> Now if only I could find the rest of the Ada libraries ported to
> C++. I got attached to concise syntax very quickly. (Yes, before
> anyone asks, I want to find Haskell-like brace/semicolon rules in
> a C++ preprocessor)
> 
> Cheers,
> Chris

Hey, aesthetics are hard to argue.

- Ed

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

[Kaz Kylheku]

In article <3B71CEEC.D5A9D001@mediaone.net>, Ed Falis wrote:
>is safety by default vs safety by proactivity.  As far as I can tell
>after a lot years working with it, there is no Ada thing oriented
>towards throwing away flexibility, nor towards force.

Sure there is: strong static typing, inability to compute data that can be
evaluated as code, lack of lexical closures, no code-transforming macros.
Users of languages that have these things look upon languages like C++
and Ada as blunt instruments from the stone age.

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:
> > Chris Wolfe wrote:
> > 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).

Noted :)

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

I am comparing comparable things. You talk of rare versions of things
in C++, whereas in the norm, the protections you talk about, are
not there.

As someone else pointed out, even the GCC with the patches installed
for doing array bounds is not only very limited, but shakey as well
(bugs).

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

I can believe that, if I could only believe that you never used
regular arrays. I've seen enough C++ code to know better than
to trust that no bare naked arrays of characters, ints, or 
whatever gets coded in C++. But every C++ fan seems to side-step
that issue.

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

I'd rather have the safety over flexibility on flight software! I
don't care what your credentials are ;-)  Frankly, I'd say the
same about my mutual fund account, bank account or mortgage too.
Safety is not somebody elses problem any more. It should be 
everyone's concern.

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

Duh, but you can be assured that all Ada references to the 
"wrapper class" arrays _are_ checked. So there. ;-)

The combination of knowing the compiler is checking everything, and
the fact that Ada is designed to be audited, makes it much easier
to say that it is "flight ready".

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

But your seat belt is a little more like a piece of string. ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Chris Torek]

In article <3B6F3216.F410BBFF@home.com>
Warren W. Gay VE3WWG <ve3wwg@home.com> writes:
>Not only that, C/C++ _cannot_ provide [array bounds] checks.

We have proof by counterexample that C compilers *can* do this,
because Bounds-Checking GCC exists.  (It is not the only one that
does it, but it is an easy way to demonstrate it.)

It *is* true that typical C compilers do not even attempt to
check array subscripts, but this is implementation, not specification.
(Ada programmers, at least, ought to know the difference. :-) )
-- 
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.

[Warren W. Gay VE3WWG]

Chris Torek wrote:
> 
> In article <3B6F3216.F410BBFF@home.com>
> Warren W. Gay VE3WWG <ve3wwg@home.com> writes:
> >Not only that, C/C++ _cannot_ provide [array bounds] checks.
> 
> We have proof by counterexample that C compilers *can* do this,
> because Bounds-Checking GCC exists.  (It is not the only one that
> does it, but it is an easy way to demonstrate it.)

Well, I didn't actually intend for this to mean that it is impossible--
only that it is generally not done, nor is mandated. In Ada, this
type of thing cannot be omitted.. otherwise it ain't Ada.

At what version of GCC did this feature go in?  What does it do
at runtime when the array bounds are exceeded? Exception? Abort?

> It *is* true that typical C compilers do not even attempt to
> check array subscripts, but this is implementation, not specification.
> (Ada programmers, at least, ought to know the difference. :-) )

Ada programmers don't need to worry about it because it is always
available in their compilers. However, they may have to turn the
runtime checks on however, depending upon the compiler used.

Anyway, I will repeat that I didn't mean that it was impossible.
Only that most compiler do _not_ make this an option (ie. you have
no choice in the matter).

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

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

[Larry Kilgallen]

In article <MJMb7.26900$B37.545436@news1.rdc1.bc.home.com>, kaz@ashi.footprints.net (Kaz Kylheku) writes:
> In article <3B6F5BB2.A879B933@worldnet.att.net>, James Rogers wrote:
>>   generic
>>   
>>   Max_Size : Positive;
>>   type Items is private;
>>   
>>   package Inventory is
>>   
>>      subtype Buf_Index is Positive range 1..Max_Size;
>>      type Parts_Buffer is array(Buf_Index) of Items;
> 
> By the way, is there a reason why you didn't just use a modulo
> type as the array index, one that will automatically wrap around
> 1..Max_Size-1?

One excellent reason might be that you don't want to wrap around.

I cannot imagine many circumstances in which one whould want to
silently wrap an index into a buffer.

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

[Larry Kilgallen]

In article <made-on-a-macintosh-1382310-28353@usenet.l1t.lt>, "Daniel Fischer" <dan@gueldenland.de> writes:

> This is nothing personal. It's just that I don't think a thread about the
> pros and cons of Ada crossposted to cl.c and cl.c++ was such a good idea.

A lot of us Ada folk have always felt the same way.

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

[Ted Dennison]

In article <slrn9mlqp3.56q.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben
Randhol says...
>
>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.

Perhaps, but I think all this talk overstates the case on the supposed speed
penalty of array bounds checks. It usually isn't that much. First off, it
doesn't affect all code, just array indexing. Secondly, optimizers can often get
rid of the checks, or hoist them out of loops (something that is probably more
difficult, if not impossible, for checks you put in yourself manually in C).
Thirdly, if you find it *is* a real impact in some instance, you can just turn
them off (locally, or for the whole program). 

So really we are talking about trading a *theoretical* minor speed difference
(which may not even exist in reality, and can be gotten rid of with a little
work if it *does* exist) for safety (in the aggregate, a guaranteed lower
occurance of bugs and security breaches). That's not much of a trade in my book.
The "black-hat" security experts at CotDC seem to agree. :-)

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

The thing that always bothers me about the "speed" argument is that there
are really only a very small number of applications where it makes any
difference. In all the rest of the applications, whatever (probably small,
as you point out) penalty exists for having the checks in is usually grossly
overshadowed by other inefficiencies in the design - running a descent
profiler would spot you lots of places where you could buy back the overhead
a hundredfold. And in most cases, it just plain doesn't matter. In your
typical user app, most of the time is spent waiting for the user to key
something in or click a button. Try compiling one of those sorts of apps
with Ada runtime checks turned off and see if there is any performance
improvement you can even notice. It might be measurable, but probably not
noticable. A difference that makes no difference, *is* no difference!

And ultimately, if you *really* persist in being an optimization freak about
it, just compile with the checks off and you're still ahead of the game
because a) you had the compile time checks that eliminated a certain
collection of errors already and b) you're getting code that is going to be
just as fast - maybe faster - than equivalent code from C (All other things
being equal, of course. You've always got that business of language
implementations varying so it is impossible to compare the efficiency of two
languages - only their realizations.)

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:mlDa7.16628$ar1.61586@www.newsranger.com...
>
> So really we are talking about trading a *theoretical* minor speed
difference
> (which may not even exist in reality, and can be gotten rid of with a
little
> work if it *does* exist) for safety (in the aggregate, a guaranteed lower
> occurance of bugs and security breaches). That's not much of a trade in my
book.
> The "black-hat" security experts at CotDC seem to agree. :-)
>

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 <3b6a453c.1193942215@news.worldonline.nl>,
> Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> >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.

Since when does programming start with applying fingers to keyboard?

Richard

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

[Dan Cross]

In article <3b6e4ab8.1457529830@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>cross@augusta.math.psu.edu (Dan Cross) wrote:
>> In article <3b6a453c.1193942215@news.worldonline.nl>,
>> Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>> >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.
>
>Since when does programming start with applying fingers to keyboard?

These days, most of the time.  :-)  But then, that's my point; it's a bad
idea.

	- Dan C.

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 <3b6e4ab8.1457529830@news.worldonline.nl>,
> Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> >cross@augusta.math.psu.edu (Dan Cross) wrote:
> >> In article <3b6a453c.1193942215@news.worldonline.nl>,
> >> Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> >> >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.
> >
> >Since when does programming start with applying fingers to keyboard?
> 
> These days, most of the time.  :-)  But then, that's my point; it's a bad
> idea.

Well, then, what's your point in contrasting "programming defects" with
"design defects"?

Richard

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

[Dan Cross]

In article <3b6ea1c1.1479814516@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>> >> Huh?  ``Design as you go'' is rarely a good strategy; you should always
>> >> have some idea how to start before applying fingers to keyboard.
>> >
>> >Since when does programming start with applying fingers to keyboard?
>> 
>> These days, most of the time.  :-)  But then, that's my point; it's a bad
>> idea.
>
>Well, then, what's your point in contrasting "programming defects" with
>"design defects"?

``Programming,'' to me, means the ``act of programming.''  This
involves thinking and typing, mostly.  The software development process
involves a lot more than just programming, including, but not limited
to, requirements gathering and analysis, design, and testing.

When you say ``programming,'' you lead me to believe you are refering
to the act of writing code, overall, a very small part of the over all
process.

But, these aren't just my terms, they're industry standard with slight
variances in nomenclature (requirements ellicitation versus gathering,
and so forth).

Anyway, as regards your question: I drew a distinction to highlight the
fact that mistakes can be made at very stages and levels of the
software development process.  Sometimes, they happen in the design of
the system, sometimes in the implementation or actual programming.

Unfortunately, these days, a lot of programs just look like random
typing.  The programmer won't even make an effort to keep his or her
software tidy looking.

	- 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:
> 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 average car driver does not buy a car limited to 20km/hour.

Safety measures are one part of the equation. It's obviously always
a trade-off between safety and speed (among other things). Balancing the
discussion to only one side of the medal (the side that shines
for Ada) is unfair. We could just as easily turn the tables and
discuss some things where Ada just doesn't cut it.

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 <v6pmk9.313.ln@10.0.0.2>,  <Bart.Vanhauwaert@nowhere.be> 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).

>Safety measures are one part of the equation. It's obviously always
>a trade-off between safety and speed (among other things). Balancing the
>discussion to only one side of the medal (the side that shines
>for Ada) is unfair. We could just as easily turn the tables and
>discuss some things where Ada just doesn't cut it.

But Ada performance is very good, as has been pointed out.

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.

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

[Mark Wilden]

<Bart.Vanhauwaert@nowhere.be> wrote in message
news:fjouk9.2ua.ln@10.0.0.2...

> 'Good enough' is a perfectly valid argument which ALSO applies
> to medical instruments and flight gear.

The recent decision not to mandate nonflammable jet fuel is a good example.

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

[Mark Wilden]

"Mark Wilden" <mark@mwilden.com> wrote in message
news:tn676giehovifc@news.supernews.com...
> <Bart.Vanhauwaert@nowhere.be> wrote in message
> news:fjouk9.2ua.ln@10.0.0.2...
>
> The recent decision not to mandate nonflammable jet fuel is a good
example.

Just to clarify, I was talking about the "inerting" of gas tanks.

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

[Bart.Vanhauwaert]

Mark Wilden <mark@mwilden.com> wrote:
>> The recent decision not to mandate nonflammable jet fuel is a good
> example.
> Just to clarify, I was talking about the "inerting" of gas tanks.

Well, it is still not clear to me what you mean. :)

cu bart

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

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

[Mark Wilden]

<Bart.Vanhauwaert@nowhere.be> wrote in message
news:33l0l9.0rj.ln@10.0.0.2...
> Mark Wilden <mark@mwilden.com> wrote:
> >> The recent decision not to mandate nonflammable jet fuel is a good
> > example.
> > Just to clarify, I was talking about the "inerting" of gas tanks.
>
> Well, it is still not clear to me what you mean. :)

It was a reference to an item in the news lately.

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

[Joona I Palaste]

Mark Wilden <mark@mwilden.com> scribbled the following
on comp.lang.c:
> <Bart.Vanhauwaert@nowhere.be> wrote in message
> news:fjouk9.2ua.ln@10.0.0.2...

>> 'Good enough' is a perfectly valid argument which ALSO applies
>> to medical instruments and flight gear.

> The recent decision not to mandate nonflammable jet fuel is a good example.

If you ask me, non-flammable fuel for anything is a pretty bad idea.

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/

"To doo bee doo bee doo."
   - Frank Sinatra

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

[Marin David Condic]

Failure of software is 100% due to mistakes made by the author. :-) This is
true no matter what language you are talking about. As was pointed out
elsewhere, there is a philosophical difference between Ada and C/C++ - one
in which Ada's philosophy is "include safety by default" whereas C/C++'s
philosophy is "Add the safety in for yourself if you think you need it."
Since in my experience, computer programmers are in most respects similar to
human beings and human beings make mistakes on a regular basis, I prefer to
have the machine (language) do as much checking for me as possible. This is
not dissimilar to having a spell-checker within a word processor. It won't
stop you from saying something stupid, but at least when you do say
something stupid, it will not have the easily detected spelling and
gramatical mistakes that are commonly made.

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/


<Bart.Vanhauwaert@nowhere.be> wrote in message
news:ldbsk9.1gl.ln@10.0.0.2...
>
> 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.
>

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

[Joachim Durchholz]

Marin David Condic wrote:
> Failure of software is 100% due to mistakes made by the author. :-)

Wrong. A sizable fraction is due to misunderstandings between author and
customer (or whoever writes the specifications), and it's not always the
author who's responsible for them.

> This is
> true no matter what language you are talking about.

This is indeed true.
The language with does still matter, of course. Since the number of bugs
is roughly proportional to lines of code, a language that expresses much
in few lines of code (without becoming obfuscated!) is at an advantage
here. Abstraction facilities are important here; and the ability to
abstract from stuff like memory management and similar things, at least
at higher levels of the software, is important for that.
Note that I say "at an advantage", not "better" - to be productive, you
need access to libraries, a debugger, maybe a profiler, maybe a GUI
builder, maybe other things depending on the task at hand. The language
itself is important, but the paraphernalia have beome *very* important
in the last decade.

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 <9kup40$6pomr$1@ID-9852.news.dfncis.de>, "Joachim Durchholz" <joachim_d@gmx.de> writes:
> Marin David Condic wrote:
>> Failure of software is 100% due to mistakes made by the author. :-)
> 
> Wrong. A sizable fraction is due to misunderstandings between author and
> customer (or whoever writes the specifications), and it's not always the
> author who's responsible for them.

It was a mistake by the author to accept an ambiguous specification.
If the specification is unambigous but not what the customer wanted,
that is not a failure of the software.

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

[Joachim Durchholz]

Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
> "Joachim Durchholz" <joachim_d@gmx.de> writes:
> > Marin David Condic wrote:
> >> Failure of software is 100% due to mistakes made by the author. :-)
> >
> > Wrong. A sizable fraction is due to misunderstandings between author
and
> > customer (or whoever writes the specifications), and it's not always
the
> > author who's responsible for them.
>
> It was a mistake by the author to accept an ambiguous specification.

Or an inconsistent one, for that matter.

However, specifications are never complete. If the customer were able to
write a complete specification, he wouldn't need a programmer after all.
And it's the missing parts that give rise to the usual problems.

> If the specification is unambigous but not what the customer wanted,
> that is not a failure of the software.

Technically not, but it creates exactly the same sort of hassles as a
programmer mistake.

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.

[Ketil Z Malde]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> In article <9kup40$6pomr$1@ID-9852.news.dfncis.de>, "Joachim Durchholz" <joachim_d@gmx.de> writes:
> > Marin David Condic wrote:
> >> Failure of software is 100% due to mistakes made by the author. :-)

>> Wrong. A sizable fraction is due to misunderstandings between author and
>> customer (or whoever writes the specifications), and it's not always the
>> author who's responsible for them.

> It was a mistake by the author to accept an ambiguous specification.
> If the specification is unambigous but not what the customer wanted,
> that is not a failure of the software.

You might as well say it was a mistake by the customer to hire an
author that makes mistakes.

I don't think this is leading anywhere.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

[Mark Wilden]

"Joachim Durchholz" <joachim_d@gmx.de> wrote in message
news:9kup40$6pomr$1@ID-9852.news.dfncis.de...
> Marin David Condic wrote:
> > Failure of software is 100% due to mistakes made by the author. :-)
>
> Wrong. A sizable fraction is due to misunderstandings between author and
> customer (or whoever writes the specifications), and it's not always the
> author who's responsible for them.

Who is responsible for avoiding such misunderstandings? Hint: if the author
doesn't take this responsibility, he'll end up without any customers to
misunderstand.

I'm not saying the customer is always right. But they're paying us, not the
other way around.

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

[Marin David Condic]

Well, I suppose we could play The Blame Game, but I was thinking about
mistakes made by people vs mistakes made by machines. Software doesn't kill
people - Programmers do. (Or customer specifiers or compiler writers or
government auditors, or... You get the idea.)

The notion I was thinking of was the one expressed a couple of posts back
that the software libraries or tools make 1% of the mistakes and the other
99% are due to the programmer. I'd contend that 0% of the mistakes are made
by the libraries or tools - the mistakes are creditable to some human being
somewhere who didn't account for all the possibilities that might occur.
That's why I favor machine-checking for errors. The more machine checking
that can be done, the less liklihood that something gets missed. The more a
computer language is capable of (and does) checking for errors, the less
liklihood that a human error is going to kill someone.

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/


"Joachim Durchholz" <joachim_d@gmx.de> wrote in message
news:9kup40$6pomr$1@ID-9852.news.dfncis.de...
> Marin David Condic wrote:
> > Failure of software is 100% due to mistakes made by the author. :-)
>
> Wrong. A sizable fraction is due to misunderstandings between author and
> customer (or whoever writes the specifications), and it's not always the
> author who's responsible for them.
>

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

[Nicholas James NETHERCOTE]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

>Since in my experience, computer programmers are in most respects similar to
>human beings and human beings make mistakes on a regular basis, I prefer to
>have the machine (language) do as much checking for me as possible. This is
>not dissimilar to having a spell-checker within a word processor. It won't
>stop you from saying something stupid, but at least when you do say
>something stupid, it will not have the easily detected spelling and
>gramatical mistakes that are commonly made.

Well said.

--
Nick Nethercote
njn[AT]cs.mu.oz.au

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

[Richard Heathfield]

Marin David Condic wrote:
> 
> Failure of software is 100% due to mistakes made by the author. :-) This is
> true no matter what language you are talking about. As was pointed out
> elsewhere, there is a philosophical difference between Ada and C/C++ - one
> in which Ada's philosophy is "include safety by default" whereas C/C++'s
> philosophy is "Add the safety in for yourself if you think you need it."
> Since in my experience, computer programmers are in most respects similar to
> human beings and human beings make mistakes on a regular basis, I prefer to
> have the machine (language) do as much checking for me as possible. This is
> not dissimilar to having a spell-checker within a word processor. It won't
> stop you from saying something stupid, but at least when you do say
> something stupid, it will not have the easily detected spelling and
> gramatical mistakes that are commonly made.

The trouble with programs like, four eggs ample, spell checkers, is
there tendency two give yew a level of confidence inn yore output witch
mite knot bee just if fried.

People who trust computers scare me. (Mind you, people who trust people
scare me too.)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

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

[Marin David Condic]

Never said you couldn't have errors escape a spell checker. Never said you
couldn't have errors escape a language implementation that has error
checking features. Never said you should implicitly trust that just because
something got past such a compiler that it was free from errors. What I
*did* say was that machine checking for routine errors would result in a
reduction of errors.

Maybe what I don't understand is why there seems to be such a resistance to
the concept of automated error checking in a computer language when we
routinely build in all sorts of automatic error checking into our software
to prevent end-users from making stupid mistakes. A simple data entry
program routinely edits the input applying various sanity checks and
refusing to accept something known to be in error. The more sanity checks we
put in - the better we think we're doing our job. Why is it appropriate for
us to build that into the end-user's application but it is somehow or other
A Bad Thing(tm) for the language/compiler designers to build that into *our*
user input program? (Oh. That's right. I forgot. Programmers are *above*
mere mortals. :-)

Accounting systems that prevent users from entering in bad data reduce the
"flexibility" the end user has with an unedited input. Payroll programs that
sanity-check paycheck data might lull the end user into a false sense of
security - getting them to "trust" computers too much. Maybe we should
propose that all input keyed in by end users should be accepted as raw
binary data and we should never check it for validity since obviously this
seems to be what we are demanding for ourselves from our computer languages.

And by the way, maybe we should all go back to computing logarithms with a
slide rule since pocket calculators lull us into a false sense of security
about our computations and how accurate they are. Or let's bag it
alltogether and go back to computing things with a pencil and paper since
this is the "ultimate" in "flexibility".

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/


"Richard Heathfield" <binary@eton.powernet.co.uk> wrote in message
news:3B738145.CC94E732@eton.powernet.co.uk...
>
> The trouble with programs like, four eggs ample, spell checkers, is
> there tendency two give yew a level of confidence inn yore output witch
> mite knot bee just if fried.
>
> People who trust computers scare me. (Mind you, people who trust people
> scare me too.)
>

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

[Kaz Kylheku]

In article <9l0o87$duo$1@nh.pace.co.uk>, Marin David Condic wrote:
>Never said you couldn't have errors escape a spell checker. Never said you
>couldn't have errors escape a language implementation that has error
>checking features. Never said you should implicitly trust that just because
>something got past such a compiler that it was free from errors. What I
>*did* say was that machine checking for routine errors would result in a
>reduction of errors.
>
>Maybe what I don't understand is why there seems to be such a resistance to
>the concept of automated error checking in a computer language when we
>routinely build in all sorts of automatic error checking into our software
>to prevent end-users from making stupid mistakes. A simple data entry
>program routinely edits the input applying various sanity checks and
>refusing to accept something known to be in error.

We do these things for convenience. By validating data at the system
boundaries, we then don't have to have error checks related to this data
at module boundaries within the system, which would be inconvenient and
error-prone. Robustness is provided most easily by filtering input close
to the points where it enters the software.

Similarly, run time checks for array overruns and such provide debugging
convenience, because an error is caught at an early point. (Though not
the earliest possible point, of course: such failures are the result
of faulty logic which led to the computation of the bad value).

I agree with you that run time checks do not suppress any useful form
of flexibility, but I don't think that it's Richard Heathfield's position
at all that useful flexibility is provided by weakening the run time
checks.  You are arguing against a position that I know he does not hold.

The position he does seem to hold is that run-time checks are training
wheels for weak programmers, or something along those lines.  To an
extent that is true.  I agree with the general idea that a solid engineer
should be able to design a correct program in the absence of a computer,
rather than rely on trial-and-error design at the computer, whereby
we just bang the program out, see if it violates some run-time-checks
and then fix them. But of course, reasonable proponents of checking do
not hold the position that development should be done this way. They
still strive to write programs that do not trigger any of these checks.
Real world programs are too complex, and worked on by too many people
of varying quality, to be designed and implemented correctly. So then
testing is relied upon, and run-time checks support that testing.

I hold the view that run time checks are bad for programmer education,
because novices will simply learn rely on them for trial-and-error
programming, whereby they don't understand why a program is wrong,
or how to design a correct one. They simply try things, and then react
to error messages.  The best teaching language would be one in which
an error is caught, but its source is not revealed. The programmer
is informed that the program failed, and the student must find the error
by reading and analyzing the program. Moreover, the student should be
able to produce a correct program on paper, and this skill should be
verified by examinations in which no computers are permitted.

I also believe that tools which allow errors to pass undiagnosed, and
even allow erroneous programs to compute the expected result, are equally
bad for education, because they entrench the view that any program is
correct if it causes the machine to produce an expected result. Hence the
abstract rules of a programming language fall by the wayside.  Many C
and C++ programmers continue to hold this view long after completing
their formal education, and even after years of experience.

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

[Ulf Wiger]

>>>>> "Kaz" == Kaz Kylheku <kaz@ashi.footprints.net> writes:

  Kaz> The position he does seem to hold is that run-time checks are
  Kaz> training wheels for weak programmers, or something along those
  Kaz> lines.  To an extent that is true.  I agree with the general
  Kaz> idea that a solid engineer should be able to design a correct
  Kaz> program in the absence of a computer, rather than rely on
  Kaz> trial-and-error design at the computer, whereby we just bang
  Kaz> the program out, see if it violates some run-time-checks and
  Kaz> then fix them.

This is a widely held opinion, which also has great appeal to
management. Too often, I encounter glib claims that formal design
is the way to go - that we should just do some more thinking before 
we attack the keyboards. Then we will finally be able to build 
systems that work.

The thing that often gets lost is the realisation that experienced
engineers of complex software systems will always do both, and 
understand that success lies in a careful mix of thinking, modeling
and experimentation.

Furthermore, some engineers are great at experimentation while others
are better at static analysis and modeling; you do not often see 
both qualities well represented in the same person.

Our approach is to program in Erlang, which is fun to program in, 
but still possesses most of the qualities of a high-level modeling
language. It also has strong run-time type checking and support
for building "self-healing" systems. Our products must function
well even in the presence of errors (and we don't pretend that 
we can eliminate errors during the design phase.)

  Kaz> But of course, reasonable proponents of checking
  Kaz> do not hold the position that development should be done this
  Kaz> way. They still strive to write programs that do not trigger
  Kaz> any of these checks.

Absolutely. We try to foster a zero-tolerance attitude towards 
run-time errors during design and testing. We also tell our 
programmers to write programs so that they either work as 
intended or crash. That way we can find the errors and fix them.
Declarative symbolic languages are absolutely wonderful for this.

  Kaz> Real world programs are too complex, and
  Kaz> worked on by too many people of varying quality, to be designed
  Kaz> and implemented correctly. So then testing is relied upon, and
  Kaz> run-time checks support that testing.

I often encounter problems which seem to defy analysis, but can still
be solved through experimentation -- it will just be extremely painful
until we stop running around in circles and try to build something
and watch it crash. Only then do we begin to understand the problem.

Having said that, it's not unusual in our environment to spend 
6 months to a year analysing a problem before we start implementing.
The trick is finding a balance.

  Kaz> I hold the view that run time checks are bad for programmer
  Kaz> education, because novices will simply learn rely on them for
  Kaz> trial-and-error programming, whereby they don't understand why
  Kaz> a program is wrong, or how to design a correct one. They simply
  Kaz> try things, and then react to error messages.  The best
  Kaz> teaching language would be one in which an error is caught, but
  Kaz> its source is not revealed.

He he, I'd just love to have a program written in such a language
running in an unattended mission-critical embedded system.  (:

Perhaps the best teaching tools do not have to be useful outside the
classroom?

BTW, I think C and C++ programs have a tendency to behave exactly like
that: they dump core, and if you're lucky, the core can actually be 
analysed. Otherwise, your only hope is to try to reproduce the 
situation with an instrumented system.

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB

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

[Andreas Rossberg]

Marin David Condic wrote:
> 
> Failure of software is 100% due to mistakes made by the author. :-) This is
> true no matter what language you are talking about.

Well, there are these languages that are so utterly complex and
ill-designed that no existing compiler implements them correctly - not
even remotely...

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids.
 If Pac Man affected us as kids, we would all be running around in
 darkened rooms, munching pills, and listening to repetitive music."

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

[AG]

<Bart.Vanhauwaert@nowhere.be> wrote in message
news:ldbsk9.1gl.ln@10.0.0.2...
> Dan Cross <cross@augusta.math.psu.edu> wrote:

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

Sorry? About 100% of the mistakes written are written by the programmer.
No escaping that. However, what about the probability of them happening
and the tools that would/could catch even some small percentage of that?

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

[Ed Falis]

Bart.Vanhauwaert@nowhere.be wrote:

> Safety measures are one part of the equation. It's obviously always
> a trade-off between safety and speed (among other things). Balancing the
> discussion to only one side of the medal (the side that shines
> for Ada) is unfair. We could just as easily turn the tables and
> discuss some things where Ada just doesn't cut it.

Well, since this thread basically started out as what appears to be a
troll, go for it!

(I'm an Ada and other language aficionado, myself).  But the exercise
could be interesting.

- Ed

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

[Marin David Condic]

Without wanting to start another flame war....

Could you elaborate on where you think that Ada doesn't cut it? I ask out of
curiosity - not as a challenge. I'll contend that Ada doesn't quite fit very
small machines - at least if someone wants to debat that, I'd ask to see
some implementations targeted to very small SBCs. All the ones I've seen
typically at least have a C compiler available and Ada developers have
pretty much ignored that niche. (Maybe you *can* fit it to small computers,
but people don't seem to be doing that in droves...)

Also "rapid prototyping" and one-shot programs of the sort that typically
get written in scripting languages is not Ada's strong suit - but that's not
saying a lot because C and C++ aren't as well suited to that as other
scripting languages. (And I know I've done some quick & dirty hacks in Ada
when I've had libraries of domain specific code lying around & got the job
done quicker than I would with anything else - but that's more a case of the
libraries I had available rather than the language itself.)

Otherwise, Ada is a general purpose language like C or C++ & I'm not sure
I'd agree that there is some problem space addressed by C or C++ that isn't
fit for Ada as well. That's why I'm curious about where you think it doesn't
fit well.

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/


<Bart.Vanhauwaert@nowhere.be> wrote in message
news:v6pmk9.313.ln@10.0.0.2...
> Safety measures are one part of the equation. It's obviously always
> a trade-off between safety and speed (among other things). Balancing the
> discussion to only one side of the medal (the side that shines
> for Ada) is unfair. We could just as easily turn the tables and
> discuss some things where Ada just doesn't cut it.

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:
> Without wanting to start another flame war....

That'll will be hard, given the Newsgroups: line this article carries,
but anyway.

> Could you elaborate on where you think that Ada doesn't cut it? I ask out of

The simple fact that Ada is not supported by Microsoft makes it
a second hand choice for most (if not all) desktop type applications. 

(I am not saying this is a good thing, this is just a fact and it
is true for a great many more promising languages, like Java for
example. This might even become true for C/C++ if C# really takes
off and Microsoft itself isn't killed before that time frame)

Granted, this says little or nothing about Ada as a language. But
I think a balanced decision on which language to use on which
platform needs to take the language platform (and support thereof)
very serious.

To say something positive of Ada : I am gratefull that it was
apperantly a good testbed of generic programming. I think that
paradigm is nearly as valuable as object oriented programming.

> Otherwise, Ada is a general purpose language like C or C++ & I'm not sure
> I'd agree that there is some problem space addressed by C or C++ that isn't
> fit for Ada as well. That's why I'm curious about where you think it doesn't
> fit well.

I think Ada as a language certainly is a general purpose language
and it can be used that way. Personally, my sole experience with
Ada was through some ill-fated courses at university. I didn't
like the verbosy style it seems to share with pascal/modula/cobol/...
But that's just personal preference i guess. Some like it terse,
others want programming languages to more closely approximate english
sentences.

cu bart

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

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

[Marin David Condic]

O.K. That's fair - or at least semi-fair. I have argued in this forum in the
past (even recently) that Ada needs the kind of IDE & tools that come with
MSVC++ if it wants to be considered for that application domain. Its hard to
argue with the leverage one gets from the MFC, etc.

However, I wouldn't consider that a *language* issue, per se. That's more of
a *tools* issue - one which is valid, but not one which makes Ada itself
unfit for developing apps for a PC platform.

Besides - there *are* tools out there that *do* provide similar capabilities
to things like MSVC++ - Aonix and RR Software (Claw) have some commercial
stuff for building GUI's, etc. under Windows. Gnat can be had with the
GtkAda environment, the gdb debugger, etc. I think this is definitely an
area for improvement (mostly by way of nicely integrating everything), but
there are tools to compete in that market.

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/


<Bart.Vanhauwaert@nowhere.be> wrote in message
news:g2qpk9.d6m.ln@10.0.0.2...
>
> The simple fact that Ada is not supported by Microsoft makes it
> a second hand choice for most (if not all) desktop type applications.
>
> (I am not saying this is a good thing, this is just a fact and it
> is true for a great many more promising languages, like Java for
> example. This might even become true for C/C++ if C# really takes
> off and Microsoft itself isn't killed before that time frame)
>
> Granted, this says little or nothing about Ada as a language. But
> I think a balanced decision on which language to use on which
> platform needs to take the language platform (and support thereof)
> very serious.
>

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

[Fergus Henderson]

Bart.Vanhauwaert@nowhere.be writes:

>Safety measures are one part of the equation. It's obviously always
>a trade-off between safety and speed (among other things). Balancing the
>discussion to only one side of the medal (the side that shines
>for Ada) is unfair. We could just as easily turn the tables and
>discuss some things where Ada just doesn't cut it.

Such as?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

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

[tmoran]

>Exploitable buffer overflows are a known *class* of bugs that are pretty
>much endemic with C (and C++ that uses C) code.
   Of course they also depend on not using hardware designed with
security in mind.

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

[Florian Weimer]

tmoran@acm.org writes:

>>Exploitable buffer overflows are a known *class* of bugs that are pretty
>>much endemic with C (and C++ that uses C) code.

>    Of course they also depend on not using hardware designed with
> security in mind.

Could you elaborate on that, please?

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

[tmoran]

> >    Of course they also depend on not using hardware designed with
> > security in mind.
>
> Could you elaborate on that, please?
   In the '60s and '70s there was quite a lot of work on "descriptors" or
"capabilities" based architectures.  The Burroughs machines (often used by
banks, interestingly) used those techniques.  The 386 was designed with a
lot of support for OS security(1), most of which is unused today.
"Protected mode" today means "wide addressing" much more than it means
protection.  At the very least, one would expect protection against
modifying running code (by running past a data buffer).
1) See, for instance, Microprocessors, A Programmer's View, by Dewar and
Smosna, p. 90 "Protection Mechanisms".

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

[Florian Weimer]

tmoran@acm.org writes:

>> >    Of course they also depend on not using hardware designed with
>> > security in mind.
>>
>> Could you elaborate on that, please?
>    In the '60s and '70s there was quite a lot of work on "descriptors" or
> "capabilities" based architectures.  The Burroughs machines (often used by
> banks, interestingly) used those techniques.  

Ah, I see.  Here's an interesting resource:

        http://www.ajwm.net/amayer/papers/B5000.html

| For additional security, code and data were distinguished in memory by
| the use of a "flag bit", and the hardware would not execute data or
| alter code without first having explicitly changed the flag (something
| reserved for privileged processes).

This protects at least against some buffer overflow exploits, 

> The 386 was designed with a lot of support for OS security(1), 

Actually, it was the 286.  The 386 introduced another VM layer which
supports paging, IIRC.

> most of which is unused today.

The 386 doesn't implement fine-grained per-object security, that's why
this scheme not very useful in this context.  Nowadays, there a tons
of exploits which overwrite function pointers on the heap, for example
to defeat Solar Designer's hack for non-executable stack pages.

All in all, the security features provided by the 386 are quite poor.
It doesn't even support the full range of mmap() flags: you cannot
control read and execution access separately.  For this, you would
need selectors (a 286 feature), and for several technical reasons, it
is not feasible to use them.

> "Protected mode" today means "wide addressing" much more than it means
> protection.  At the very least, one would expect protection against
> modifying running code (by running past a data buffer).

That's not how buffer overflows work. ;-)

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

[tmoran]

> Ah, I see.  Here's an interesting resource:
>
>         http://www.ajwm.net/amayer/papers/B5000.html
  Ah, nostalgia.  As a student assistant I worked on a B5500 MCP.
I hope many of the good ideas of the last 40 years will be rediscovered
by the end of the next 40.

> > The 386 was designed with a lot of support for OS security(1),
>
> Actually, it was the 286.  The 386 introduced another VM layer which
> supports paging, IIRC.
   Wasn't the 286 selector stuff a whole lot simpler than the 386?
Is it the case that it was impossible, or at least nobody ever
managed, to make an OS that actually used the 386 stuff?

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

[Dale Pontius]

In article <Ax3a7.21447$Kd7.13454602@news1.rdc1.sfba.home.com>,
        tmoran@acm.org writes:
>> Ah, I see.  Here's an interesting resource:
>>
>>         http://www.ajwm.net/amayer/papers/B5000.html
>   Ah, nostalgia.  As a student assistant I worked on a B5500 MCP.
> I hope many of the good ideas of the last 40 years will be rediscovered
> by the end of the next 40.
>
>> > The 386 was designed with a lot of support for OS security(1),
>>
>> Actually, it was the 286.  The 386 introduced another VM layer which
>> supports paging, IIRC.
>    Wasn't the 286 selector stuff a whole lot simpler than the 386?
> Is it the case that it was impossible, or at least nobody ever
> managed, to make an OS that actually used the 386 stuff?

I think you have it partly backwards. The 286 had all the selector
stuff, and OS/2 1.x used it, as well as the DPMS specs, which Windows
sort of used through Win3.1. (Maybe afterward too, but I'm not sure.)
Then the 386 came out with true paging and the like, and selectors
were pretty much dropped. I'm not sure if there's any involvement
with selectors in Xeon 36-bit addressing, or not.

Dale Pontius
NOT speaking for IBM

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

[Florian Weimer]

pontius@btv.ibm.com (Dale Pontius) writes:

> I think you have it partly backwards. The 286 had all the selector
> stuff, and OS/2 1.x used it, as well as the DPMS specs,

DPMI, I think.  Windows implemented only part of this specification
(0.9 instead of 1.0, or something like that), and some programs
required 1.0, so this was quite an awkward situation.

> which Windows sort of used through Win3.1. (Maybe afterward too, but
> I'm not sure.)

There were other DPMI implementations, and some are still used today
(like Windows 3.1 ;-).

> Then the 386 came out with true paging and the like, and selectors
> were pretty much dropped. I'm not sure if there's any involvement
> with selectors in Xeon 36-bit addressing, or not.

PAE is implemented very late in the process of mapping logical
addresses to physical ones.  You can't have two selectors which access
separate memory regions to get rid of the 4 GB limit.

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

[Florian Weimer]

tmoran@acm.org writes:

>> Actually, it was the 286.  The 386 introduced another VM layer which
>> supports paging, IIRC.

>    Wasn't the 286 selector stuff a whole lot simpler than the 386?

I don't think so.  You already had those four rings (courtesy of
Multics, I guess), this mysterious ARPL instruction, call gates,
etc. etc.

In fact, the 386 is simpler than the 286 for implementing C-oriented
operating systems because of the additional VM layer which permits an
unsegmented address space for user-mode programs.

> Is it the case that it was impossible, or at least nobody ever
> managed, to make an OS that actually used the 386 stuff?

I don't know.  Perhaps you can implement the Ada rendezvous
efficiently using call gates.

Some of the stuff is of course used by each modern operating system,
in order to switch to protected mode.  But Linux, for example, does
all the fancy stuff using the additional VM layer which was added by
the 386.

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

[chris.danx]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87r8uvuu48.fsf@deneb.enyo.de...
> tmoran@acm.org writes:
>
> >> >    Of course they also depend on not using hardware designed with
> >> > security in mind.
> >>
> >> Could you elaborate on that, please?
> >    In the '60s and '70s there was quite a lot of work on "descriptors"
or
> > "capabilities" based architectures.  The Burroughs machines (often used
by
> > banks, interestingly) used those techniques.
>
> Ah, I see.  Here's an interesting resource:
>
>         http://www.ajwm.net/amayer/papers/B5000.html

That is just plain rediculous!  What a lot of s**t!  I cannot gain access to
it simply because I'm an IE user!

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

[chris.danx]

"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:9hja7.1803$tQ5.728008@news2-win.server.ntlworld.com...
>
> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> news:87r8uvuu48.fsf@deneb.enyo.de...
> > tmoran@acm.org writes:
> >
> > >> >    Of course they also depend on not using hardware designed with
> > >> > security in mind.
> > >>
> > >> Could you elaborate on that, please?
> > >    In the '60s and '70s there was quite a lot of work on "descriptors"
> or
> > > "capabilities" based architectures.  The Burroughs machines (often
used
> by
> > > banks, interestingly) used those techniques.
> >
> > Ah, I see.  Here's an interesting resource:
> >
> >         http://www.ajwm.net/amayer/papers/B5000.html
>
> That is just plain rediculous!  What a lot of s**t!  I cannot gain access
to
> it simply because I'm an IE user!

Pardon my language, I was somewhat annoyed by that.

My appologies,
Chris

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

[Hartmann Schaffer]

In article <5ee5b646.0108010949.5abab7fe@posting.google.com>,
	dewar@gnat.com (Robert Dewar) writes:
> "Mike Smith" <smithmc@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpmb575l80@corp.supernews.com>...
>> "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?
> 
> 
> Sounds like Mike is not familiar with Ada. Of course Ada does not
> guarantee freedom from bugs, but for many reasons it does tend to
> eliminate obvious goofs like buffer overruns, which are indeed
> "endemic" to C and C++ in that these languages do not provide any
> help for avoiding such bugs, and as we know these buffer overrun
> bugs have time and time again proved weak spots in code written
> in C/C++.

to be fair, afaik many implementations of the C library still contains
the old getline(?) macro which is unsafe.  but the problem has been
recognized for over 20 years now, everybody is strongly advised to use
the (safe) fgetline, and afaik it is not in the standard any more.
you really can't blame the language for some idiot coders

hs

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

[Florian Weimer]

hs@heaven.nirvananet (Hartmann Schaffer) writes:

> to be fair, afaik many implementations of the C library still contains
> the old getline(?) macro which is unsafe.  but the problem has been
> recognized for over 20 years now, everybody is strongly advised to use
> the (safe) fgetline, and afaik it is not in the standard any more.

Of course it's in the standard, of course it's not deprecated, of
course the security implications aren't mentioned.  Why should the C
standard bother with that?

strncpy() with completely bogus semantics is still there, too.

Regarding the subject line, I doubt that Ada would have made any
difference.  Quite a few providers were DDoSed because of what I
consider a design error in routers used for IP accounting.  Ada
wouldn't have helped here, I'm afraid.

The other DoS aspect of the worm (weak PRNG without proper seed) was
corrected in a later version and would not have been avoided by using
Ada (see A.5.2(28)).

IMHO, the Code Red worm itself is extraordinarily harmless, in
particular the second version.

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

[David Lee Lambert]

On 1 Aug 2001, Robert Dewar wrote:

> "Mike Smith" <smithmc@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpmb575l80@corp.supernews.com>...
> > "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?
>
> Sounds like Mike is not familiar with Ada. Of course Ada does not
> guarantee freedom from bugs, but for many reasons it does tend to
> eliminate obvious goofs like buffer overruns, which are indeed
> "endemic" to C and C++ in that these languages do not provide any
> help for avoiding such bugs, and as we know these buffer overrun
> bugs have time and time again proved weak spots in code written
> in C/C++.

C++ makes it very easy to avoid buffer-overflow bugs:  just use the STL
types 'string' (for strings) and 'vector<T>' (for arbitrary objects).

In C,  one has to think ahead a little in some situations,  but it's still
quite straightforward to write overflow-free code once one has been
introduced to the right functions:  fgets(), snprintf(), (non-ANSI)
strlcpy()...

Agreed that there is a lot of buggy C code out there.  Much of it is the
result of assumptions made in laboratory conditions on machines with a lot
of performance-limitations;  for instance,  80-column TTYs and printers
and card-punches.  These assumptions started out with FORTRAN and other
languages of that era;  C was the beginning of the process to supersede
them.

The Ada language does seem to provide some bounds-checking...

"3.6.1 Index Constraints and Discrete Ranges

(1)
     An index_constraint determines the range of possible values for every
index of an array subtype, and thereby the corresponding array bounds. "

It is true that C and C++ native types do not provide bounds-checking,
although some compilers do bounds-checking for static arrays.  However, it
would be trivial to make a type or system like vector<T> with the
additional feature of doing automatic bounds-checking, or even
automatically growing the array when adding a new element past the end.

Whether such an implementation would really be efficient is another
question -- in many cases it would be better to use a hash or tree
structure for such a random-access application.  C forces a person to
think about the consequences of poor algorithm choices.

Certainly, scripting languages like Perl and VBA and Basic and *sh and
lisp and Java avoid many of these errors, but most implementations of such
languages are written in C, often using standard components like yacc().
(I do know of one book on compiler-design that uses Java for
implementation, and I'm sure that Pascal was widely used at one time, but
C still reigns supreme...)  Note that Perl has a way to call
C/assembler/Fortran libraries,  but no way to use a templatized C++
library using all of the OOP features (sorry if this is over-general...).


I'm sure that one can write a secure webserver in Ada,  but I personally
would trust a mission-critical system that I had written in C better,
because I've had more experience with the language and the available
environment.  I certainly would plan out such a system very carefully.

--
DLL

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

[David Wagner]

David Lee Lambert  wrote:
>C++ makes it very easy to avoid buffer-overflow bugs:  just use the STL
>types 'string' (for strings) and 'vector<T>' (for arbitrary objects).

I claim that this is primarily a library issue, not a language issue.
It would also be easy to write libraries for C to avoid buffer-overflow
bugs: Just provide a 'string' abstract data type that can only be
manipulated by library functions and ensure that all those library
functions do proper bounds-checking.  (So why doesn't everyone do this?
My answer: legacy code, and legacy programmers.)

Note also that while buffer overruns in strings may be the most common
cause of buffer overrun vulnerabilities, one should not overlook overruns
in anything that manipulates arrays and pointers directly.  Preventing
the latter requires more than C++'s 'string' type or safe libraries; it
requires programmer discipline or support from the programming language.

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

[Marcin 'Qrczak' Kowalczyk]

Sat, 4 Aug 2001 14:36:10 -0400, David Lee Lambert <lamber45@egr.msu.edu> pisze:

> C++ makes it very easy to avoid buffer-overflow bugs:  just use the STL
> types 'string' (for strings) and 'vector<T>' (for arbitrary objects).

They don't prevent buffer overflows. Their operator[] doesn't check the
index range (I know that there is also at() method) and stepping their
iterators past the end is undefined behavior, not a detected error.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST�PCZA
QRCZAK

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

[Preben Randhol]

On Sat, 4 Aug 2001 14:36:10 -0400, David Lee Lambert wrote:

> I'm sure that one can write a secure webserver in Ada,  but I personally
> would trust a mission-critical system that I had written in C better,
> because I've had more experience with the language and the available
> environment.  I certainly would plan out such a system very carefully.

I can understand your argument that you know C better and more
comfortable with it, but it is not a valid argument when one make
mission-critical software like airplane systems, train, nuclear power
plants etc...

Your problems also lies in that C has unsafe pointers and no strict
typing. Another problem is that C scales very poorly, leading to obscure
code.

I personally would disembark an airplane if they said that the software
is written in C. If it is written in Ada I would have stayed.

I encourage you to try out Ada a bit and I really think that you will
change your mind about which language you want to use in critical
software. It really is a huge difference from C.

Here you find the design goals of Ada: 
   http://www.adapower.com/rm95/arm95_3.html#SEC3

And here is an article from Business Week, which is a interest read: 

Software Hell (int'l edition)

Glitches cost billions of dollars and jeopardize human lives. How can we
kill the bugs?

[...]
   �With the low points of just the past 24 months, you could build a
   Software Hall of Infamy. In a fast-flowing river of woe, software
   bugs--along with viruses and security loopholes--have plagued most
   new releases of Microsoft Windows and Office products, Netscape
   Navigator, Intuit's Quicken, and countless other personal-computer
   applications. Glitches have crippled online auctions and trading
   sites and delayed product shipments at Hershey (HSY), Whirlpool
   (WHR), and Handspring, maker of Visor palm computers. All told, bad
   software cost U.S. businesses $85 billion in lost productivity last
   year, according to Jim Johnson, president of market researcher The
   Standish Group in Dennis, Mass.�
[...]

whole article here:

   http://www.businessweek.com/1999/99_49/b3658015.htm

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.

[Attila Feher]

raj wrote:
[SNIP]
> 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.

Just one _short_ comment to this over-discussed thread: C/C++ are power
tools.  They need professionals to work with them securely.  I am very
sure that lame programmers can do lame things in Ada as well.  Point is:
as you don't give a chainsaw to a debil and then complain about the
damage... the same way one should use or make use of powerful languages
like C and C++.  It is not the chainsaw and not C or C++.  It is the
people using it.

A

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

[Simon Wright]

Attila Feher <Attila.Feher@lmf.ericsson.se> writes:

> Just one _short_ comment to this over-discussed thread: C/C++ are
> power tools.  They need professionals to work with them securely.  I
> am very sure that lame programmers can do lame things in Ada as
> well.  Point is: as you don't give a chainsaw to a debil and then
> complain about the damage... the same way one should use or make use
> of powerful languages like C and C++.  It is not the chainsaw and
> not C or C++.  It is the people using it.

I am sure that properly-written C++ code can provide a lot of the
protection that we Ada users expect.

But a lot of "professional" (what does that mean? paid? certified?
member of the ACM? competent? my friends?) people get to write in
C. And I've seen them not even use ANSI function prototypes ..

I would have thought a professional woodworker who chose to use a
circular saw without the guard wouldn't be so much professional as
foolish ..

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.

[Joona I Palaste]

Will <wv9557@yahoo.com> scribbled the following
on comp.lang.c:
> 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.

Well, before Dennis Ritchie got his hands on the PDP-7 (PDP-9)
computer over at Bell Labs, there was no C OS either. That didn't stop
him from writing C. Why can't the same be applied to Ada?

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/

"No, Maggie, not Aztec, Olmec! Ol-mec!"
   - Lisa Simpson

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

[Rajat Datta]

On 12 Aug 2001 17:38:45 GMT, Joona I Palaste <palaste@cc.helsinki.fi> wrote:
>Well, before Dennis Ritchie got his hands on the PDP-7 (PDP-9)
>computer over at Bell Labs, there was no C OS either. That didn't stop
>him from writing C. Why can't the same be applied to Ada?

The question is not why couldn't it; the question is why hasn't it?

rajat

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

[Dillo]

On 12 Aug 2001 17:38:45 GMT, Joona I Palaste <palaste@cc.helsinki.fi>
wrote:

>Will <wv9557@yahoo.com> scribbled the following
>on comp.lang.c:
>> 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.
>
>Well, before Dennis Ritchie got his hands on the PDP-7 (PDP-9)
>computer over at Bell Labs, there was no C OS either. That didn't stop
>him from writing C. Why can't the same be applied to Ada?

That's not the ADA way. In ADA land you would first have to form a
committee to define the perfect computer. Then you would need another
committee to define the perfect OS. Once all of that committee work
was done, after a few decades, you could begin.

Wait a minute...that sounds a lot like how things are done in C++
land!!

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

[Gautier]

Will:

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

It's terrible.
But do you worry about the fact that Cobol, Fortran and Visual Basic
do rule the world ?

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

Hey, good idea - for Windows 98 it is tempting sometimes. If you think
about the full development time (almost 20 years, with DOS, Win 3.1 etc.)
of this gem of OSes, the millions of users-buyers behind it, and the
resulting quality (especially the page-fault blue screens), it is definitely
a success of the pointer-to-buffer macro-assemblers.

> See if you are left with an OS to write your Ada application.
> Die, Ada, Die.

Beware the hatred overflow!
____________________________________________________
Gautier -- http://www.mysunrise.ch/users/gdm/e3d.htm

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

[Tore Lund]

Gautier wrote:
> 
> Windows 98 ... a success of the pointer-to-buffer macro-assemblers.

Please don't blame assembler for Win98.  And there is nothing wrong
about using pointers to buffers.  The trouble starts when you misuse
them.
-- 
    Tore

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

[Tim Robinson]

"Will" <wv9557@yahoo.com> wrote in message
news:4a885870.0108112341.7ce02ac0@posting.google.com...
| theory: you could have write a better OS than NT, Linux, SunOS with
Ada
| Fact: there is *NO* Ada OS

I think such an OS, AdaOS, is under development: www.adaos.org.

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

[tmoran]

| Fact: there is *NO* Ada OS
  What do you call the thing that does the functions of an OS in
an airplane's flight control system?  A subway car? etc.

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

[Tony Gair]

These guys are heroes, every single one and if you can't give financial or 
sexual favours then give them a good bit of encouragement,

 
Regards
Tony Gair

Remember before you embark on your crusade ,
Keep away from darkness and mystery,
Do not allow them to wonder away and think,
For it is easier to hold ten cats on the end of one finger,
Than to control and direct a single one of these 
                God forsaken Creatures.

"The  Submission and control of Software Engineers"
                Leto Atreides II

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

[Marin David Condic]

I admire anyone with a willingness to tilt at windmills. :-)

I truly hope that the AdaOS project makes some headway. However, I've been
occasionally dropping by the website for some time now and have yet to see
anything really concrete show up there. I would have hoped by now that they
might have succeeded in getting a boot loader or kernel implemented far
enough to actually have something up and cycling on a machine. Or at
minimum, have a design document of some sort in some stage of completion.

I realize that this is a volunteer effort and its hard to pick on people who
are committing their time to a worthwhile project. Its just that we've been
hearing about AdaOS and citing it as an example for so long with absolutely
nothing concrete to point to that I'm beginning to wonder if maybe we just
should treat it with a little "Benign Neglect" and see if maybe one day
anything gets off the ground with it. I don't think we should be pointing
people (*especially* in other newsgroups) at a project and citing it saying:
"See???? Ada can be used to build an OS!!!" if you have no concrete results
there of any kind. It only invites the (valid) criticism of "I'll believe it
when I see it..."

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/


"Tony Gair" <tonygair@nospammey.blueyonder.co.uk> wrote in message
news:9IFe7.12813$6R6.1221214@news1.cableinet.net...
>
> These guys are heroes, every single one and if you can't give financial or
> sexual favours then give them a good bit of encouragement,
>

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> I admire anyone with a willingness to tilt at windmills. :-)
> 
> I truly hope that the AdaOS project makes some headway. However, I've been
> occasionally dropping by the website for some time now and have yet to see
> anything really concrete show up there. I would have hoped by now that they
> might have succeeded in getting a boot loader or kernel implemented far
> enough to actually have something up and cycling on a machine. Or at
> minimum, have a design document of some sort in some stage of completion.
> 
> I realize that this is a volunteer effort and its hard to pick on people who
> are committing their time to a worthwhile project. Its just that we've been
> hearing about AdaOS and citing it as an example for so long with absolutely
> nothing concrete to point to that I'm beginning to wonder if maybe we just
> should treat it with a little "Benign Neglect" and see if maybe one day
> anything gets off the ground with it. 

The problem in a nutshell seems to be the idea that they need to build their
own Ada compiler first, which I see as an extremely ambitious plan. It seems
to make more sense to adapt (if necessary) the existing GNAT compiler, and then
get on with the actual OS code. If we wait for the compiler to be built, then
I think things will remain the "debating society" that it seems to be.

I'm not criticizing anyone that wants to take on such a project (as a hobby),
but it seems to me that the scope of it almost guarantees that it won't 
get done.  It would be better to build some parts of the OS, and do the compiler
later, if the compiler is that important, IMHO.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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

[Ted Dennison]

In article <4a885870.0108112341.7ce02ac0@posting.google.com>, Will says...
>theory: you could have write a better OS than NT, Linux, SunOS with Ada
>Fact: there is *NO* Ada OS 

I hate to respond to an obvious troll, but I'm worried someone might take this
seriously. There are actually quite a few OS's out there written in Ada.
However, none of them happen to be named "Unix", or "Windows", so most people
don't ever bump into one of them.

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

[Martin Dowie]

er, fiction, actually...

Raytheon's RT-Secure is an all Ada product and I think Aonix have another.
Not sure what Rational R-1000 environment was writen in but that was an
Ada-environment in that the 'OS' commands were Ada subprogram calls, etc...
I'll snip myself here before rambling much further  ;-)

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

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.

[Markus Mottl]

In comp.lang.functional Larry Kilgallen <Kilgallen@spamcop.net> wrote:
> 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 ? :-)

What concerns me, I'd rather expect scenarios like some unsuspecting US
general clicking on "Go home" in Explorer running on the same network
as a mid-flight nuke, which could lead to unexpected results...

I am a hobby astronomer: I always wanted to watch Redmond in orbit :->

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.

[Richard Bos]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote:

> In article <3b83847d.1117251944@news.worldonline.nl>, info@hoekstra-uitgeverij.nl (Richard Bos) writes:
>
> > 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.

I was mainly considering the possibility that so many ships would lock
up before they got anywhere that they would give up altogether. Oh,
blissful state of rest! :-)

Richard

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

[Markus Mottl]

In comp.lang.functional Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> 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 ;->.

I'd suggest that a new ABM-treaty be written, which allows the US to
build ABMs against the former agreements, but requires them to let these
missiles be controlled by Windows CE. I'd feel much safer this way... ;)

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 <9m07uk$jn0$1@bird.wu-wien.ac.at>, Markus Mottl says...
>
>I'd suggest that a new ABM-treaty be written, which allows the US to
>build ABMs against the former agreements, but requires them to let these
>missiles be controlled by Windows CE. I'd feel much safer this way... ;)

Actually, to be safe under that system, you'd have to make sure *you* are the
country antagonizing the US, and *not* one of their neighbors...

---
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 Ted Dennison <dennison@telepath.com> wrote:
> In article <9m07uk$jn0$1@bird.wu-wien.ac.at>, Markus Mottl says...
>>I'd suggest that a new ABM-treaty be written, which allows the US to
>>build ABMs against the former agreements, but requires them to let these
>>missiles be controlled by Windows CE. I'd feel much safer this way... ;)

> Actually, to be safe under that system, you'd have to make sure *you* are the
> country antagonizing the US, and *not* one of their neighbors...

Well, currently it seems the US is not particularly interested in
improving foreign relations to _any_ country. Showing intentions to
break the ABM-treaty doesn't make nor keep friends...

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.

[Daniel C. Wang]

Markus Mottl <mottl@miss.wu-wien.ac.at> writes:

{stuff deleted}
> Well, currently it seems the US is not particularly interested in
> improving foreign relations to _any_ country. Showing intentions to
> break the ABM-treaty doesn't make nor keep friends...

s/US/current "elected" administration/g

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

[Larry Kilgallen]

In article <bvOg7.10377$2u.73660@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> 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...

Those of us who sometimes move about in sailboats are not so flip :-)

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

[Richard Riehle]

Richard Bos wrote:

regarding greater dependence on NT by the U.S. Navy,

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

It is my impression that some in the Navy are finally discovering
the horrors of depending on Microsoft products.   Unfortunately,
not enough, yet.

Meanwhile, there will be a presentation by two officers from the
U.S. Navy at this year's SigAda conference demonstrating a system
developed using GtkAda that runs on Linux as well as on NT.   In
fact, the way this system was designed, it will run on any system
where GtkAda is available.   A demonstration version of this software
will probably be fielded, at sea, soon on a Linux laptop to see what else
is required to make it a viable tool.

Someone told me recently that he thought avoiding the use of any Microsoft
product in favor of Linux or MacIntosh was an act of patriotism.  Interesting
idea, though probably a bit over the top.  Personally, I would like to see
IBM resurrect OS/2 since it seems more secure than anything Microsoft
has at present or projected for the future.

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

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

[Vincent Marciante]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3B84A208.736FD73F@adaworks.com...
...

> Personally, I would like to see
> IBM resurrect OS/2 since it seems more secure than anything Microsoft
> has at present or projected for the future.

www.ecomstation.com   (multiprocessor version also available!)


Vinny

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

[Warren W. Gay VE3WWG]

Richard Riehle wrote:
> Richard Bos wrote:
> regarding greater dependence on NT by the U.S. Navy,
> 
> > That is good news. For the rest of us, that is ;->.
> 
> It is my impression that some in the Navy are finally discovering
> the horrors of depending on Microsoft products.   Unfortunately,
> not enough, yet.
...
> ... Personally, I would like to see
> IBM resurrect OS/2 since it seems more secure than anything Microsoft
> has at present or projected for the future.

AFAIK, OS/2 was all/mostly written in assembly language. That does
not inspire much confidence, IMO.  I also remember those friendly
OS/2 errors "O/S Error # 301... Have a nice day.." (some
exageration included) ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

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.

[Joachim Durchholz]

Markus Mottl <mottl@miss.wu-wien.ac.at> wrote:
> 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).

Hmm. Looks as if NT wasn't really responsible, the thing was still under
test.

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.

[Markus Mottl]

In comp.lang.functional Joachim Durchholz <joachim_d@gmx.de> wrote:
> Hmm. Looks as if NT wasn't really responsible, the thing was still
> under test.

It is true that the weapons control software was under test, but the
same was _not_ true for the NT-server as such. A server that controls
the network of a whole battle cruiser just must not go down due to some
fault in an application.

Several sources cite navy engineers who are extremely discontent about
NT being used instead of Unix. Sure, no OS gives you 100% guarantees,
but it's common knowledge among sysadmins that NT is significantly less
stable than high-end Unix systems. I am not speaking of Linux here,
which is not (yet) high-end in several critical aspects, but many people
would still prefer it over NT.

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 <9m08tm$bsbo3$1@ID-9852.news.dfncis.de>, Joachim Durchholz says...
>
>Markus Mottl <mottl@miss.wu-wien.ac.at> wrote:
>> 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).
>
>Hmm. Looks as if NT wasn't really responsible, the thing was still under
>test.

:-)

You clearly don't know much about the Navy to say this. You don't debug Navy
engine controllers by putting them on a 1$ billion Cruiser with a proud captain
and a full compliment of crew and having them steam around a bit to see what
happens. Having a failure so bad that a ship has to be towed is *the* nightmare
scenario in the naval engine controller biz. Its a public humiliation for the
captain, and you can trust that heads *will* roll over it. Even after that, the
captain is probably *never* going to trust that company's engine controllers
again. If he one day gets into the procurement side, that could be disasterous
for them.

Any engine controller should have been completely debugged *years* before it
ever touched a ship. The fact that there were still simple bugs at this point is
a *scathing* inditment of something. We can argue over what that thing is, but
there is no argument that is was a big deal.

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

Consider that a Naval vessel is a weapon of war whos purpose is to protect
the shores of the nation. Even if it is on a testing cruise, it could at any
moment be called upon to do combat. At any moment, it could be fired upon by
an unfriendly power and need to defend itself. Shake down cruise or not,
that vessel always needs to be prepared to face a possible attack. There's
no way the captain could go to an enemy submarine "Hey guys... 'Time Out'?
I've got engine control problems..." It is ultimately the responsibility of
the captain of the vessel to be sure that when he puts to sea, his boat is
prepared for whatever it may face. Having to have it towed back to port is
evidence on the face of it that he didn't do his job right. (You're testing
an engine control? Why didn't you have a known, reliable unit on-board as
backup in the event this unproven one broke? Hmmmm????)

People who have played the DoD game know that what we are building is
serious as hell and it cannot fail or lives and the nation itself are at
risk. Failure isn't an option. That's one of the reasons that Ada is
important to critical defense systems.

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:rCPg7.10478$2u.74412@www.newsranger.com...
>
> You clearly don't know much about the Navy to say this. You don't debug
Navy
> engine controllers by putting them on a 1$ billion Cruiser with a proud
captain
> and a full compliment of crew and having them steam around a bit to see
what
> happens. Having a failure so bad that a ship has to be towed is *the*
nightmare
> scenario in the naval engine controller biz. Its a public humiliation for
the
> captain, and you can trust that heads *will* roll over it. Even after
that, the
> captain is probably *never* going to trust that company's engine
controllers
> again. If he one day gets into the procurement side, that could be
disasterous
> for them.
>
> Any engine controller should have been completely debugged *years* before
it
> ever touched a ship. The fact that there were still simple bugs at this
point is
> a *scathing* inditment of something. We can argue over what that thing is,
but
> there is no argument that is was a big deal.
>

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

[Markus Mottl]

In comp.lang.functional Ted Dennison <dennison@telepath.com> wrote:
> In article <9m0193$grs$1@bird.wu-wien.ac.at>, Markus Mottl says...
>>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.

I was referring to the ship as a whole when I mentioned "weapons
technology". The Navy surely has reasons to keep up a positive image of
their technology, not only to give a secure feeling to the people it's
supposed to protect, but also to threaten potential aggressors. Saddam
certainly had a good laugh... ;)

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.

[Stefan Skoglund]

Ted Dennison wrote:
> 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.

Hrrmm, i got a idea for a good ECM system some days ago.
Look for exploitable overflow bugs in some communication system.
Put a transmitter in a missile there the transmitter is able to send
its rootkit and have the kit penetrate the enemy's CIWS system...

(well it is hack of the 4tf July movie)

Would it be possible to insert such a thing into a jtids system ?