How to make Ada a dominant language

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

[Preben Randhol]

In article <3B6555ED.9B0B0420@sneakemail.com>, Russ Paielli wrote:
> Preben Randhol wrote:
> 
> 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.

So what. If they choose not to use Ada because one uses a more readable
syntax, let them. They obviously haven't grasphed the idea of making
good quality software and are only too happy hacking in C or Perl or
whater. Let them. I think rather that this 90% are either ignorant of
Ada or following the main stream towards the cliffs (read C++, Java
etc...).

> Because "=" is the simplest fricking symbol that could possibly be used

If you think about it it is more important that your if statments are
correct than your assignments. Just think about this C line:

   if (C = crap) then ...

and of course it will always be true and will compile. I would rather
have = for this than assignments.

> for assignment. Why is this so hard for Ada programmers to understand?
> What's so great about ":="? Why not use "$=" or "%="?

Because of how colon is used in written language. You can read := as
"set to equal" or only "set to".


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

Sorry but you are barking up the wrong tree as I see it. Rather make
good free programs in Ada and distribute them under GPL or similar with
source to get more people aware of Ada. That would help Ada more than
changing its syntax.


-- 
�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 <3B6555ED.9B0B0420@sneakemail.com>, Russ Paielli wrote:
> > Preben Randhol wrote:
> >
> > 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.
> 
> So what. If they choose not to use Ada because one uses a more readable
> syntax, let them. They obviously haven't grasphed the idea of making
> good quality software and are only too happy hacking in C or Perl or
> whater. Let them. I think rather that this 90% are either ignorant of
> Ada or following the main stream towards the cliffs (read C++, Java
> etc...).
> 
> > Because "=" is the simplest fricking symbol that could possibly be used
> 
> If you think about it it is more important that your if statments are
> correct than your assignments. Just think about this C line:
> 
>    if (C = crap) then ...
> 
> and of course it will always be true and will compile. I would rather
> have = for this than assignments.

This is a red herring. You simply don't allow "if (C = crap) then". As I
wrote in my proposal, you use "==" for equality testing IF (IF IF IF IF
IF) it causes any confusion with assignment.

> > for assignment. Why is this so hard for Ada programmers to understand?
> > What's so great about ":="? Why not use "$=" or "%="?
> 
> Because of how colon is used in written language. You can read := as
> "set to equal" or only "set to".

Then why not just use the colon, without the equals. The ":=" is
redundant. I have yet to see ":=" used in anything I have ever read.
That is NOT how the colon is used in the written language.

> > 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.
> 
> Sorry but you are barking up the wrong tree as I see it. Rather make
> good free programs in Ada and distribute them under GPL or similar with
> source to get more people aware of Ada. That would help Ada more than
> changing its syntax.

I think you are barking up the wrong tree. Not only that, you are
putting the cart before the horse. Why do you think so few open-source
programs are written in Ada? I just hope folks like you wake up before
Ada goes the way of HAL and Jovial.

Russ

Re: How to make Ada a dominant language

[Preben Randhol]

In article <3B655FF1.F5268A37@sneakemail.com>, Russ Paielli wrote:
> 
> I think you are barking up the wrong tree. Not only that, you are
> putting the cart before the horse. Why do you think so few open-source
> programs are written in Ada? I just hope folks like you wake up before
> Ada goes the way of HAL and Jovial.

Certainly not because the syntax is not like C's.

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

[Gary Scott]

Hey! we still use Jovial a bunch...

Russ Paielli wrote:
> 
> Preben Randhol wrote:
> >
> > In article <3B6555ED.9B0B0420@sneakemail.com>, Russ Paielli wrote:
> > > Preben Randhol wrote:
> > >
> > > 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.
> >
> > So what. If they choose not to use Ada because one uses a more readable
> > syntax, let them. They obviously haven't grasphed the idea of making
> > good quality software and are only too happy hacking in C or Perl or
> > whater. Let them. I think rather that this 90% are either ignorant of
> > Ada or following the main stream towards the cliffs (read C++, Java
> > etc...).
> >
> > > Because "=" is the simplest fricking symbol that could possibly be used
> >
> > If you think about it it is more important that your if statments are
> > correct than your assignments. Just think about this C line:
> >
> >    if (C = crap) then ...
> >
> > and of course it will always be true and will compile. I would rather
> > have = for this than assignments.
> 
> This is a red herring. You simply don't allow "if (C = crap) then". As I
> wrote in my proposal, you use "==" for equality testing IF (IF IF IF IF
> IF) it causes any confusion with assignment.
> 
> > > for assignment. Why is this so hard for Ada programmers to understand?
> > > What's so great about ":="? Why not use "$=" or "%="?
> >
> > Because of how colon is used in written language. You can read := as
> > "set to equal" or only "set to".
> 
> Then why not just use the colon, without the equals. The ":=" is
> redundant. I have yet to see ":=" used in anything I have ever read.
> That is NOT how the colon is used in the written language.
> 
> > > 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.
> >
> > Sorry but you are barking up the wrong tree as I see it. Rather make
> > good free programs in Ada and distribute them under GPL or similar with
> > source to get more people aware of Ada. That would help Ada more than
> > changing its syntax.
> 
> I think you are barking up the wrong tree. Not only that, you are
> putting the cart before the horse. Why do you think so few open-source
> programs are written in Ada? I just hope folks like you wake up before
> Ada goes the way of HAL and Jovial.
> 
> Russ

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B655FF1.F5268A37@sneakemail.com>...

> I think you are barking up the wrong tree. Not only that, you are
> putting the cart before the horse. Why do you think so few open-source
> programs are written in Ada? I just hope folks like you wake up before
> Ada goes the way of HAL and Jovial.
> 
> Russ


Seriously, I think you are the one barking up the wrong tree, and not
only that, you are also the one who puts his cart in front of the
horse. In addition, you are climbing down the tree head down.  :)

Adrian Hoe

Re: How to make Ada a dominant language

[Darren New]

> > What's so great about ":="? Why not use "$=" or "%="?
> 
> Because of how colon is used in written language. You can read := as
> "set to equal" or only "set to".

Actually, it's because there was no left-arrow on hollerith cards. := is
as close to a left-pointing arrow that you could draw without using <=
or <- both of which would be confusing for different reasons.

-- 
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 to make Ada a dominant language

[Florian Weimer]

randhol@kiuk0156.chembio.ntnu.no (Preben Randhol) writes:

>> Because "=" is the simplest fricking symbol that could possibly be used
> 
> If you think about it it is more important that your if statments are
> correct than your assignments. Just think about this C line:
> 
>    if (C = crap) then ...
> 
> and of course it will always be true and will compile. I would rather
> have = for this than assignments.

This problem isn't caused by the symbol '=' per se, but by the fact
assignments are expressions, not statements, in C.

Python (another language which uses '=' and '==') gives you a
diagnostic in such cases.

Re: How to make Ada a dominant language

[Gary Lisyansky]

"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B6555ED.9B0B0420@sneakemail.com...
> Preben Randhol wrote:
> > > 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.

Dubious. In reality, only C/C++/Java use this "type first" order in
declarations. Pascal uses Ada- like syntax, VB uses even more verbose
construct (Dim Count As Integer) and so on. I've never heard anyone complain
about "var name first" declaration convention.

>
> > 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 "%="?

It's a change for the sake of change. It doesn't eliminate any serious
verbosity. ":=" is simply traditional.

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

Frankly, I think that lack of popularity of Ada has literally nothing to do
with any of the "issues" that you've listed.
>
> Russ

Gary

Re: How to make Ada a dominant language

[Russ Paielli]

Gary Lisyansky wrote:
> 
> "Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
> news:3B6555ED.9B0B0420@sneakemail.com...
> > Preben Randhol wrote:
> > > > 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.
> 
> Dubious. In reality, only C/C++/Java use this "type first" order in
> declarations. Pascal uses Ada- like syntax, VB uses even more verbose
> construct (Dim Count As Integer) and so on. I've never heard anyone complain
> about "var name first" declaration convention.

Yes, and how popular is Pascal? How popular is C/C++? Thanks for making
my point.

> >
> > > 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 "%="?
> 
> It's a change for the sake of change. It doesn't eliminate any serious
> verbosity. ":=" is simply traditional.

It's a change for the sake of simplicity. Einstein said, "Everything
should be made as simple as possible, but no simpler."

> >
> > > 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.
> 
> Frankly, I think that lack of popularity of Ada has literally nothing to do
> with any of the "issues" that you've listed.

"Literally nothing," eh? Open your eyes, before your next job requires
you to use C++ or Java!

Ada is a great language and it was mandated by the DoD for years, yet it
is still used very little by hackers or hobbyists. What could explain
that other than the tacky syntax?

Russ

Re: How to make Ada a dominant language

[Gary Lisyansky]

"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B656345.64AB603A@sneakemail.com...
> Gary Lisyansky wrote:
>
> Yes, and how popular is Pascal? How popular is C/C++? Thanks for making
> my point.

Object Pascal (in its Delphi incarnation) is in fact the most popular
RAD/database development tool in Europe. It outnumbers even VB there. C++-
based RAD/DB tools like Optima++ or C++ Builder have a very few
installations.

>
> > >
> > > > 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 "%="?
> >
> > It's a change for the sake of change. It doesn't eliminate any serious
> > verbosity. ":=" is simply traditional.
>
> It's a change for the sake of simplicity. Einstein said, "Everything
> should be made as simple as possible, but no simpler."
>
>
> Ada is a great language and it was mandated by the DoD for years, yet it
> is still used very little by hackers or hobbyists. What could explain
> that other than the tacky syntax?

The reasons are multiple. IMHO, some of them include poor availability of
compilers for most widespread hardware in the 80- 90s and many non-
technical issues.

>
> Russ

Re: How to make Ada a dominant language

[Larry Kilgallen]

One of the best things about Ada is stability. There have only been two
versions of the standard, and vendor extensions are well under control.

There are many things that can be done to make Ada more popular outside
the language definition.  Any changes to the language pale by comparison
in their effect.  Making Ada more popular would not be desireable if it
hurt the clarity and correctness advantages Ada has now.

Re: How to make Ada a dominant language

[Russ Paielli]

Larry Kilgallen wrote:
> 
> One of the best things about Ada is stability. There have only been two
> versions of the standard, and vendor extensions are well under control.

> There are many things that can be done to make Ada more popular outside
> the language definition.  Any changes to the language pale by comparison
> in their effect.  Making Ada more popular would not be desireable if it
> hurt the clarity and correctness advantages Ada has now.

My proposal is deliberately designed to have a minimal effect on
stability. As I said, a relatively simple preprocessor would be able to
translate back and forth between Ada95 and the syntax I am proposing. If
you want to continue to use Ada95 syntax, you could do so with impunity.
What's the problem?

In the meantime, the Ada community seems determined to rearrange the
chairs on the deck of the Titanic.

I read recently that only one in ten new DoD WEAPONS programs is even
choosing Ada now that the DoD mandate has been dropped. Don't even ask
about DoD accounting and supply-chain management programs!

I am trying to sell Ada for a safety-critical program, and I am getting
little or no support from my organization. I get forwarded email
messages from full professors of CS at MIT claiming that Ada is being
replaced by Java even in their studies of software reliability.

You Ada guys seem determined to let Ada slip into oblivion. I'll bet HAL
and Jovial programmers are proud of the stability of their languages
too.

I am new to Ada, and I believe that gives me a certain perspective that
Ada veterans lack. I am making a proposal that could save the best
programming language around, and all I get is a bunch of irrelevant
criticism.

Russ

Re: How to make Ada a dominant language

[Preben Randhol]

In article <3B657715.7EC592D9@sneakemail.com>, Russ Paielli wrote:
> 
> In the meantime, the Ada community seems determined to rearrange the
> chairs on the deck of the Titanic.

Since you are claiming you know better, I would like to see some
documentation that a syntax change will make hoards of programmers which
to the language.

> I am new to Ada, and I believe that gives me a certain perspective that
> Ada veterans lack. I am making a proposal that could save the best
> programming language around, and all I get is a bunch of irrelevant
> criticism.

I'm also new to Ada, but I don't agree with your arguments. Actually I
think it was very nice to come to a language were the source code is
clear and easy to read after having used languages such as C and Perl
etc...

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

[Darren New]

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

C is a sucky library programming language as well. Less sucky than a lot
of other things, but the lack of any sort of first-class non-primitive
data really bites for library development. (I.e., the fact that you
can't return a string is quite a hinderance to most of the libraries I
tend to write.)

-- 
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 to make Ada a dominant language

[Preben Randhol]

On Mon, 30 Jul 2001 17:19:32 GMT, Darren New wrote:
>> �Don't use C;  In my opinion,  C is a library programming language
>>  not an app programming language.�  - Owen Taylor (GTK+ developer)
> 
> C is a sucky library programming language as well. Less sucky than a lot
> of other things, but the lack of any sort of first-class non-primitive
> data really bites for library development. (I.e., the fact that you
> can't return a string is quite a hinderance to most of the libraries I
> tend to write.)

I agree fully with you, but I think there is more to gain for Ada if one
use it first to develop new apps, then later libraries/OSes :-)

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

[David Starner]

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

Darren New <dnew@san.rr.com> wrote in message
news:3B659726.33E301CA@san.rr.com...
>> �Don't use C;  In my opinion,  C is a library programming language
>>  not an app programming language.�  - Owen Taylor (GTK+ developer)
>
> C is a sucky library programming language as well. Less sucky than a lot
> of other things, but the lack of any sort of first-class non-primitive
> data really bites for library development. (I.e., the fact that you
> can't return a string is quite a hinderance to most of the libraries I
> tend to write.)

But it has the huge advantage of having the stablest, standardist binary API
on most systems, and being useable from almost every programming language in
active use. Often, the only safe way to connect to systems in the same
language compiled by different compilers is through a C interface.

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

Re: How to make Ada a dominant language

[Larry Kilgallen]

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

In article <9kae23$38a$1@news-central.tiac.net>, "David Starner" <dstarner98@aasaa.ofe.org> writes:
> Darren New <dnew@san.rr.com> wrote in message
> news:3B659726.33E301CA@san.rr.com...
>>> �Don't use C;  In my opinion,  C is a library programming language
>>>  not an app programming language.�  - Owen Taylor (GTK+ developer)
>>
>> C is a sucky library programming language as well. Less sucky than a lot
>> of other things, but the lack of any sort of first-class non-primitive
>> data really bites for library development. (I.e., the fact that you
>> can't return a string is quite a hinderance to most of the libraries I
>> tend to write.)
> 
> But it has the huge advantage of having the stablest, standardist binary API

I am not at all convinced that most standard goes with most stable.
You should add some proof.

> on most systems, and being useable from almost every programming language in
> active use. Often, the only safe way to connect to systems in the same
> language compiled by different compilers is through a C interface.

And "often" operating systems come from Microsoft.  Ada also has
standardized interfaces to Fortran and Cobol.

But on VMS there is a common calling standard for all languages.
I don't mean to slight any other operating systems that are
language-neutral, but the idea that interfaces between languages
might use null-terminated strings is like passing the cup around
to make sure _everybody_ gets typhoid.

Pointer arithmetic is the wave of the past.

Re: How to make Ada a dominant language

[David Starner]

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

> In article <9kae23$38a$1@news-central.tiac.net>, "David Starner"
<dstarner98@aasaa.ofe.org> writes:
> > Darren New <dnew@san.rr.com> wrote in message
> > news:3B659726.33E301CA@san.rr.com...
> >>> �Don't use C;  In my opinion,  C is a library programming language
> >>>  not an app programming language.�  - Owen Taylor (GTK+ developer)
> >>
[...]
> >
> > But it has the huge advantage of having the stablest, standardist binary
API
>
> I am not at all convinced that most standard goes with most stable.
> You should add some proof.

As a standard, there's the System V ABI, that was designed primarily for C,
and the IA64 ABI designed for C and C++.  C has standardized symbol name
mangling, something few other languages can claim.

> > on most systems, and being useable from almost every programming
language in
> > active use. Often, the only safe way to connect to systems in the same
> > language compiled by different compilers is through a C interface.
>
> And "often" operating systems come from Microsoft.  Ada also has
> standardized interfaces to Fortran and Cobol.

Ada does have standardized interfaces to Fortran and Cobol, both of which
are more or less irrelevant in the scope of Owen Taylor's work. (There's no
usable open-source Fortran 90/95 or Cobol compiler, and the number of
open-source  programs in Fortran 77 is small.) How about Objective C? How
about O'Caml? How about Perl and Python? How about Eiffel? How about
compiled (non-JVM) Java? How about Pascal? (Okay, that's little better than
Fortran.) GTK has bindings in 14 languages, including all the above but
Java.

> But on VMS there is a common calling standard for all languages.

(What does all languages mean? Surely you don't mean every language
created?)

Unfortunately, that's rare among operating systems. Pretty much every OS I'm
familiar of defines calling standards for one or two languages, and lets the
others fend for themselves.

> I don't mean to slight any other operating systems that are
> language-neutral, but the idea that interfaces between languages
> might use null-terminated strings is like passing the cup around
> to make sure _everybody_ gets typhoid.
>
> Pointer arithmetic is the wave of the past.

How do you go from null-terminated strings to pointer arithmetic? Pointer
arithmetic is orthogonal to the C calling convention. If your arrays don't
carry bounds information with them, then null-terminated strings seem a
reasonable way to go. I won't argue that the interface is wonderful, but I
could interface almost any two Ada functions through it, so it's fairly
complete and working.

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

Re: How to make Ada a dominant language

[Larry Kilgallen]

In article <9kb56v$pjr$1@news-central.tiac.net>, "David Starner" <dstarner98@aasaa.ofe.org> writes:

>> But on VMS there is a common calling standard for all languages.
> 
> (What does all languages mean? Surely you don't mean every language
> created?)

I mean all compiled languages for which there is a compiler on VMS.
Nobody, no matter how academic, would presume to provide a VMS compiler
without using the calling standard.

> Unfortunately, that's rare among operating systems. Pretty much every OS I'm
> familiar of defines calling standards for one or two languages, and lets the
> others fend for themselves.

There are are descriptors for strings, arrays and non-continguous
arrays, all with bounds information, plus lots of atomic data types.
For records, you need to use compatible record declarations (such
as those created with the SDL tool), but there is a standard for how
to lay those records out (padding and the like) followed by the
languages.

Re: How to make Ada a dominant language

[Ted Dennison]

In article <9kae23$38a$1@news-central.tiac.net>, David Starner says...
>But it has the huge advantage of having the stablest, standardist binary API
>on most systems, and being useable from almost every programming language in
>active use. Often, the only safe way to connect to systems in the same
>language compiled by different compilers is through a C interface.

So what? Its just the *interface*. Its perfectly reasonable for an OS to have a
standard calling interface for os lib's (eg: Stdcall on Win32, C on Unix), and I
know of no Ada compiler that is unable to import and export routines using the
standard OS calling interface for its platform. 

To pick a nit as well, "most systems" are Win32, which does *not* use the C
calling interface as its standard interface for OS calls. Someone else pointed
out that VMS doesn't exactly work that way either. Unix is actually the odball
here, probably due to its C heritage. 

C coders like to view things the way you state, as it reaffirms their delusion
that the world revolves around them. In fact, often a bit of work has to be done
by header file authors to interface with OS libraries, but since users don't
often write those headers, they can ignore that fact. Don't take up their myopia
as your own.

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

Re: How to make Ada a dominant language

[Darren New]

Ted Dennison wrote:
> Unix is actually the odball
> here, probably due to its C heritage.

And when you get right down to it, OS calls are never standard calls
unless your processor supports changing privledges as part of a "normal"
call. (Or unless your OS makes no such privledge distinction, of
course.)

I don't think I want to use a system trap for every function call.

-- 
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 to make Ada a dominant language

[Larry Kilgallen]

In article <3B697B8B.175A87D8@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> Ted Dennison wrote:
>> Unix is actually the odball
>> here, probably due to its C heritage.
> 
> And when you get right down to it, OS calls are never standard calls
> unless your processor supports changing privledges as part of a "normal"
> call. (Or unless your OS makes no such privledge distinction, of
> course.)

In VMS, the OS calls made by user mode programs are standard calls.
A portion of the operating system then takes that call (in user mode)
and does one of the following:

	traps to kernel mode
	traps to executive mode
	completes the work in user mode

after either of the first two, this user mode code may wait for
completion of the system service.  Since the waiting is done in
user mode, the user can interrupt it can request image rundown
or take a more innocuous action.

When discussing the universe of operating systems, it is best to
avoid use of the word "never".

Re: How to make Ada a dominant language

[Darren New]

Larry Kilgallen wrote:
> 
> In article <3B697B8B.175A87D8@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> > Ted Dennison wrote:
> >> Unix is actually the odball
> >> here, probably due to its C heritage.
> >
> > And when you get right down to it, OS calls are never standard calls
> > unless your processor supports changing privledges as part of a "normal"
> > call. (Or unless your OS makes no such privledge distinction, of
> > course.)
> 
> In VMS, the OS calls made by user mode programs are standard calls.
> A portion of the operating system then takes that call (in user mode)
> and does one of the following:
> 
>         traps to kernel mode
>         traps to executive mode
>         completes the work in user mode

Well, I'd argue that the first two aren't standard calls (they're traps)
and that the third is simply a library call. I.e., you could say the
same things about C and UNIX. "read()" is really a C call that just
happens to trap to the OS to do the work. My point was that there's a
non-standard non-C calling convention involved in OS calls even in UNIX.

That said, VMS is one of the cleanest processors for doing this sort of
stuff, which is why everyone uses the same calling convention. :-)

My point was that claiming it's easier to call the OS from C than from
(say) Ada is specious, since calling "read()" in C isn't calling the OS.
It's calling a C library function that isn't written in C and which then
calls the OS with a non-C calling convention.

> When discussing the universe of operating systems, it is best to
> avoid use of the word "never".

Or at least to be clear about what you're trying to express.

-- 
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 to make Ada a dominant language

[Larry Kilgallen]

In article <3B69A428.B31867A4@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> Larry Kilgallen wrote:
>> 
>> In article <3B697B8B.175A87D8@san.rr.com>, Darren New <dnew@san.rr.com> writes:
>> > Ted Dennison wrote:
>> >> Unix is actually the odball
>> >> here, probably due to its C heritage.
>> >
>> > And when you get right down to it, OS calls are never standard calls
>> > unless your processor supports changing privledges as part of a "normal"
>> > call. (Or unless your OS makes no such privledge distinction, of
>> > course.)
>> 
>> In VMS, the OS calls made by user mode programs are standard calls.
>> A portion of the operating system then takes that call (in user mode)
>> and does one of the following:
>> 
>>         traps to kernel mode
>>         traps to executive mode
>>         completes the work in user mode
> 
> Well, I'd argue that the first two aren't standard calls (they're traps)
> and that the third is simply a library call.

The first two are genuine standard calls, that execute code in user
mode that happens to be part of the operating system.  _That_ code
then initiates a trap.  Thus, the only interface from the user's
program (which is what I thought we were talking about) is a standard
call.

The third is not a library call because it does not call a library.
It is a call to a routine in the operating system base code that could
be changed to use executive or kernel mode in a future version without
breaking user programs.

Re: How to make Ada a dominant language

[Darren New]

> But it has the huge advantage of having the stablest, standardist binary API
> on most systems,

Sorry, more stable than assembler? Fortunately, even C++ has a mechanism
for using the C calling convention. 

> and being useable from almost every programming language in
> active use.

That too would be assembler.

So apparently, the main benefit to using C for writing libraries is that
it's really close to assembler.

Of course, the other problem is mismatches between .h and .c files, the
fact that even in *source* code you generally don't have compatibility
of function declarations[1], and the fact that C is so primitive that
it's almost impossible to take a subsection of functionality from a
program and reuse it elsewhere[2].

[1] For example, how many times have you seen macros for K&R C inside an
extern "C" macro? How often have you seen "void" or "extern" defined as
a macro?

[2] Hint: Try to take the MIME parser out of a mime-compliant email
client and see how easy it is to incorporate into a new program that
doesn't operate on mailboxes, as an example.

I don't know how much Ada does to solve [2], but my experience with C is
that it takes significant forethought to library reusability *because* C
supplies so little in the way of language capabilities, even to the
point where you have to have special conventions for returning values
from functions.


-- 
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 to make Ada a dominant language

[bruns]

 Dear Ada community,

 Let me tell you what would trigger that I use Ada for my projects:
 In short: A Ada-C Compiler would bring me to that state.

 Although I use almost exclusively Fortran,
 my projects run on all machines that have a C-Compiler.
 If I have to port my projects to a machine where no Fortran compiler
 is available for, I use a Fortran to C translator (NAG-f90).

 C is portable assembler.
 So, eg. GNAT should target C.

 No, GNAT does not run on all systems that I target:
 
 Is there a GNAT for Linux on Alpha?
 Is there a GNAT for Cray T3E? 

 Okay, I am interested mainly in high performance computing,
 so I will continue to use Fortran for the compute intensive tasks,
 but I would immediately start using Ada for the rest, as soon
 as I can be shure that, for the rest of the millenium, there will
 be a tool to transform my Ada parts to object code.
 I am shure that C and Fortran will be available until the end of
 my life. I am quite shure that C++ compilers for many machines
 will be available. Other languages ...

 Why not a Ada to C ( portable assembler ) translator?

 Warner

Re: How to make Ada a dominant language

[Pascal Obry]

bruns@tetibm2.ee.TU-Berlin.DE () writes:

>  Dear Ada community,
> 
>  Let me tell you what would trigger that I use Ada for my projects:
>  In short: A Ada-C Compiler would bring me to that state.

No problem, this beast exist. Please contact AverStar if I'm not mistaken this
is the compagny which have an Ada to C compiler.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: How to make Ada a dominant language

[Lao Xiao Hai]

Pascal Obry wrote:

> bruns@tetibm2.ee.TU-Berlin.DE () writes:
>
> >  Dear Ada community,
> >
> >  Let me tell you what would trigger that I use Ada for my projects:
> >  In short: A Ada-C Compiler would bring me to that state.
>
> No problem, this beast exist. Please contact AverStar if I'm not mistaken this
> is the compagny which have an Ada to C compiler.

Irvine Compiler Corporation also has a C-Path Ada compiler.

Richard Riehle

Re: How to make Ada a dominant language

[Marin David Condic]

It would be nice if Ada (Gnat?) were available on every platform targeting
every processor, but unfortunately with limited resources, the developers
have to concentrate on the big-ticket items. Maybe one day Ada's
proliferation will be as widespread as that of C.

I believe Averstar http://www.averstar.com/ has an Ada compiler that
translates to C, but it may require some investment to get it ported to the
platforms you are interested in. I'd contact them and see what they say...

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/


<bruns@tetibm2.ee.TU-Berlin.DE> wrote in message
news:9kcoc0$4ld$1@mamenchi.zrz.TU-Berlin.DE...
> Dear Ada community,
>
>  Let me tell you what would trigger that I use Ada for my projects:
>  In short: A Ada-C Compiler would bring me to that state.
>

Re: How to make Ada a dominant language

[Larry Kilgallen]

In article <9kcoc0$4ld$1@mamenchi.zrz.TU-Berlin.DE>, bruns@tetibm2.ee.TU-Berlin.DE () writes:
>  Dear Ada community,
> 
>  Let me tell you what would trigger that I use Ada for my projects:
>  In short: A Ada-C Compiler would bring me to that state.
> 
>  Although I use almost exclusively Fortran,
>  my projects run on all machines that have a C-Compiler.
>  If I have to port my projects to a machine where no Fortran compiler
>  is available for, I use a Fortran to C translator (NAG-f90).

The corresponding Ada product goes under the name AdaMagic (as do
some other products).  The company can be located under the name
Averstar on the www.adaic.org site (although I believe they are
changing the company name again).  The chief Ada honcho there is
Tucker Taft, who happens to have lead the Ada95 standardization
effort.  Tell him Larry Kilgallen sent you :-)

Re: How to make Ada a dominant language

[Larry Kilgallen]

In article <3B657715.7EC592D9@sneakemail.com>, Russ Paielli <18k11tm001@sneakemail.com> writes:
> Larry Kilgallen wrote:
>> 
>> One of the best things about Ada is stability. There have only been two
>> versions of the standard, and vendor extensions are well under control.
> 
>> There are many things that can be done to make Ada more popular outside
>> the language definition.  Any changes to the language pale by comparison
>> in their effect.  Making Ada more popular would not be desireable if it
>> hurt the clarity and correctness advantages Ada has now.
> 
> My proposal is deliberately designed to have a minimal effect on
> stability. As I said, a relatively simple preprocessor would be able to
> translate back and forth between Ada95 and the syntax I am proposing. If
> you want to continue to use Ada95 syntax, you could do so with impunity.
> What's the problem?

There is no problem, as a previous poster indicated, for you to devise
a syntactic equivalent to Ada.  Using keywords in French would be one
example.  You can translate back and forth, but I don't think others
will be attracted to the RUSS language.

> I read recently that only one in ten new DoD WEAPONS programs is even
> choosing Ada now that the DoD mandate has been dropped. Don't even ask
> about DoD accounting and supply-chain management programs!

Certainly those decisions are not made on the basis of the symbols
used for syntax.  Personally I am not particularly concerned with
DoD.  Consider railway and subway controls, where Europe seems to
use Ada more certainly than the US.  Perhaps some years from now
the US will commission a study regarding greater safety on the
European rail systems.  Perhaps not.  But in the meantime, there
are more immediate problems like the recent Microsoft IIS buffer
overflow problem.

> I am trying to sell Ada for a safety-critical program, and I am getting
> little or no support from my organization.

Perhaps you are not the successful salesman type.  I know that I am
not.  I see some things in unrelated areas that are sold for no good
reason at all.

> I am new to Ada, and I believe that gives me a certain perspective that
> Ada veterans lack. I am making a proposal that could save the best
> programming language around, and all I get is a bunch of irrelevant
> criticism.

Think of it as a sampling of what wider opinion would be like.  One
can write voice-of-doom headlines criticizing Ada for switching
directions according to your scenario.  One can also write such
headlines about many other scenarios.  The best thing most people
can do for Ada is to write one great program in Ada and let the
results stand for themselves.

Re: How to make Ada a dominant language

[Russ Paielli]

Larry Kilgallen wrote:
> 
> In article <3B657715.7EC592D9@sneakemail.com>, Russ Paielli <18k11tm001@sneakemail.com> writes:
> > Larry Kilgallen wrote:
> >>
> >> One of the best things about Ada is stability. There have only been two
> >> versions of the standard, and vendor extensions are well under control.
> >
> >> There are many things that can be done to make Ada more popular outside
> >> the language definition.  Any changes to the language pale by comparison
> >> in their effect.  Making Ada more popular would not be desireable if it
> >> hurt the clarity and correctness advantages Ada has now.
> >
> > My proposal is deliberately designed to have a minimal effect on
> > stability. As I said, a relatively simple preprocessor would be able to
> > translate back and forth between Ada95 and the syntax I am proposing. If
> > you want to continue to use Ada95 syntax, you could do so with impunity.
> > What's the problem?
> 
> There is no problem, as a previous poster indicated, for you to devise
> a syntactic equivalent to Ada.  Using keywords in French would be one
> example.  You can translate back and forth, but I don't think others
> will be attracted to the RUSS language.

Yes, I realize I could develop a translator independent of any official
Ada standard, and I may end up doing just that. The problem is that
gnatmake and other tools will not work properly unless I can convince
the gnatmake developers to cooperate with me.

By the way, if you think that what I am proposing is no more useful than
translating Ada keywords to French, you are obviously missing the point.
I'll give your intelligence the benefit of the doubt and assume you are
INTENTIONALLY missing the point.

Oh, you don't think that others will be attracted to the "RUSS"
language, eh? I've got news for you, dude: not many others are attracted
to Ada either, at this point.

> > I read recently that only one in ten new DoD WEAPONS programs is even
> > choosing Ada now that the DoD mandate has been dropped. Don't even ask
> > about DoD accounting and supply-chain management programs!
> 
> Certainly those decisions are not made on the basis of the symbols
> used for syntax.  Personally I am not particularly concerned with
> DoD.  Consider railway and subway controls, where Europe seems to
> use Ada more certainly than the US.  Perhaps some years from now
> the US will commission a study regarding greater safety on the
> European rail systems.  Perhaps not.  But in the meantime, there
> are more immediate problems like the recent Microsoft IIS buffer
> overflow problem.

No, language selection is not made DIRECTLY on the basis of the symbols
used in the syntax. But languages ARE often selected on the basis of
their POPULARITY. Popularity breeds more popularity, in a sort of
positive feedback mechanism. But where does the initial popularity come
from? How do languages "catch on"? I suggest it has a lot to do with how
much programmers like the language, and good programmers like a clean,
elegant syntax that is uncluttered with a bunch of extraneous crap. That
is why Python is perhaps more popular than Ada even though it has been
around only a fraction of the time.

> > I am trying to sell Ada for a safety-critical program, and I am getting
> > little or no support from my organization.
> 
> Perhaps you are not the successful salesman type.  I know that I am
> not.  I see some things in unrelated areas that are sold for no good
> reason at all.

Apparently YOU don't think I am a very good salesman :-)

> > I am new to Ada, and I believe that gives me a certain perspective that
> > Ada veterans lack. I am making a proposal that could save the best
> > programming language around, and all I get is a bunch of irrelevant
> > criticism.
> 
> Think of it as a sampling of what wider opinion would be like.  One
> can write voice-of-doom headlines criticizing Ada for switching
> directions according to your scenario.  One can also write such
> headlines about many other scenarios.  The best thing most people
> can do for Ada is to write one great program in Ada and let the
> results stand for themselves.

In the software environment I work in, nobody knows or cares about Ada.
Oh, they know it exists, but that's about all they know. If headlines
came out about Ada switching directions, it would be the best thing that
ever happened to Ada.

Russ

Re: How to make Ada a dominant language

[Marin David Condic]

IIRC, there are switches for Gnat that enable you to specify a preprocessor.
Or some other mechanism. Never used it myself, but tripped across it in the
documentation somewhere. It shouldn't be hard to use that or roll-your-own
in the form of some sort of shell script or simple program that can execute
a command line. Just read the command line, parse it to find the file,
preprocess the file and pass the result to gnatmake.

I still doubt that this will win lots of converts, but it really wouldn't be
that hard 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/


"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B6588FC.6D40C443@sneakemail.com...
>
> Yes, I realize I could develop a translator independent of any official
> Ada standard, and I may end up doing just that. The problem is that
> gnatmake and other tools will not work properly unless I can convince
> the gnatmake developers to cooperate with me.
>

Re: How to make Ada a dominant language

[Stefan Nobis]

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

> No, language selection is not made DIRECTLY on the basis of the symbols
> used in the syntax. But languages ARE often selected on the basis of
> their POPULARITY. Popularity breeds more popularity, in a sort of
> positive feedback mechanism. But where does the initial popularity come
> from? How do languages "catch on"? I suggest it has a lot to do with how
> much programmers like the language, and good programmers like a clean,
> elegant syntax that is uncluttered with a bunch of extraneous crap. That
> is why Python is perhaps more popular than Ada even though it has been
> around only a fraction of the time.

Just look at C and Perl. Both are much more popular and much more widley used
than Python but both have a very bad syntax (and some very bad
semantics). Even Javas syntax isn't very clear and readable, but even Java is
more popular than Python. So, obviously, syntax is not the imporant part in
choosing a language.

There are many very good languages in different aspects, think of OCAML,
Mozart/OZ, Common Lisp, Ruby,...

Maybe syntax should be more important, but today it is not, so changing Ada's
syntax would gain just nothing.

> In the software environment I work in, nobody knows or cares about Ada.
> Oh, they know it exists, but that's about all they know. If headlines
> came out about Ada switching directions, it would be the best thing that
> ever happened to Ada.

You will really tell me, if Ada changes ":=" to "=", your company will switch
project languages? Really? If a software developer chooses a language for his
project just because of such syntax details, i hope, i have never to use his
software!

-- 
Until the next mail...,
Stefan.

Re: How to make Ada a dominant language

[Milan Mancel]

I am new to Ada too, learning just for few weeks and I do not think
that there is any problem with Ada95 syntax. Well, I am not newbie to
programming, in my professional career I had to use many languages
(Fortran, Forth ...) and now I use Java, Python and C/C++ and I am
ready to try whatever interesting comes next and accept its syntax :)

When I started with Ada, I really had problem with statements like
count: integer := 0; - well maybe for five seconds. Then I accepted
that things are that way and that it is pretty logical:

- you say that count is integer and it si zero
- you see variables first and only if you need to know the type you
read the second word on the line

I think if someone is not able to grasp this simple thing will not be
able understand more important parts of Ada and it is good for him/her
not to try further.

The other thing - elimitating keyword "end" - no way! When I program
in Java, my code looks like:

public int someMethod() {
       blahblahblah
       ...
       ...
} // end someMethod

so I like Ada the way it is.

If you want indentation part of the language, just use command line
switch in gnatmake and incorrect indentation will generate an style
error - so you are forced to use the right style.

:= versus =, all the years I hate C and Java style, == is illogical. =
means equals. From historical reason C wanted to save every byte of
source code - and you assign more frequently than compare equality, so
with == for equality and = for assignment you save valuable bytes.
Thats is all to it. Problem is that programmers are acustommed to
this.

What really puts people off Ada is that they cannot hack code like in
C. In Ada you have to think first. You have to think of correct types
and subtypes for you data and variables first, otherwise you even
cannot pass them to library functions and procedures as parameters.
Ada is not good for testing algorithms or quick hacking. I think that
good combination is Python for prototyping and Ada for final code.

What I really miss is good and short example code of every Ada concept
and maybe more libraries and bindings.

Milan

Re: How to make Ada a dominant language

[Russ Paielli]

Milan Mancel wrote:
> 
> I am new to Ada too, learning just for few weeks and I do not think
> that there is any problem with Ada95 syntax. Well, I am not newbie to
> programming, in my professional career I had to use many languages
> (Fortran, Forth ...) and now I use Java, Python and C/C++ and I am
> ready to try whatever interesting comes next and accept its syntax :)
> 
> When I started with Ada, I really had problem with statements like
> count: integer := 0; - well maybe for five seconds. Then I accepted
> that things are that way and that it is pretty logical:

> - you say that count is integer and it si zero
> - you see variables first and only if you need to know the type you
> read the second word on the line

I understand what it means. I just find it backward. Backward does not
mean wrong, just backward. I think an initialization statement should
look like an assignment statement, so

    integer: x = 1

looks like

    x = 1

but

    x: integer := 1;

does not look like

    x := 1;

> I think if someone is not able to grasp this simple thing will not be
> able understand more important parts of Ada and it is good for him/her
> not to try further.

OK, I give up.

> The other thing - elimitating keyword "end" - no way! When I program
> in Java, my code looks like:
> 
> public int someMethod() {
>        blahblahblah
>        ...
>        ...
> } // end someMethod

I find those kinds of comments tacky. I will say, however, that if you
are going to have end statements you might as well say what you are
ending, and Ada got that right. I agree that does add to readability.

> so I like Ada the way it is.
> 
> If you want indentation part of the language, just use command line
> switch in gnatmake and incorrect indentation will generate an style
> error - so you are forced to use the right style.

I didn't realize that. Why not go a step further and MANDATE the right
structure? It would be consistent with the general Ada philosophy of
mandating daily flossing and other good habits.

Russ

Re: How to make Ada a dominant language

[Milan Mancel]

Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6627F7.8B1CC237@sneakemail.com>...

> Milan Mancel wrote:

> 
>     integer: x = 1
> 
> looks like
> 
>     x = 1
> 
> but
> 
>     x: integer := 1;
> 
> does not look like
> 
>     x := 1;


Definitely it is matter of personal taste, some like it some not.
Truth is that sometimes after all day long spent in Java and C++ it is
hard to switch to this style :)

> 
> > I think if someone is not able to grasp this simple thing will not be
> > able understand more important parts of Ada and it is good for him/her
> > not to try further.
> 
> OK, I give up.
> 

I did not meant offense, just wanted to say that there are more
important things to focus on.

> > 
> > If you want indentation part of the language, just use command line
> > switch in gnatmake and incorrect indentation will generate an style
> > error - so you are forced to use the right style.
> 
> I didn't realize that. Why not go a step further and MANDATE the right
> structure? It would be consistent with the general Ada philosophy of
> mandating daily flossing and other good habits.
> 

Well, that is not that bad idea, but I am afraid that it will break
old code.  Maybe to make style checks as default and only for
compatibility with old code use switch
-backwards-compatibility-indentation. And I do not know if other
compilers can check indentation too.

The switch is:

  -gnaty    Enable all style checks
  -gnatyxxx Enable selected style checks xxx = list of parameters:
        1-9  check indentation
        b    check no blanks at end of lines
        c    check comment format
        e    check end labels present
        f    check no form feeds/vertical tabs in source
        h    check no horizontal tabs in source
        i    check if-then layout
        k    check casing rules for keywords, identifiers
        m    check line length <= 79 characters
        Mnnn check line length <= nnn characters
        r    check RM column layout
        s    check separate subprogram specs present
        t    check token separation rules


(I personnaly hate casing rules for identifiers)


   Milan

Re: How to make Ada a dominant language

[Ted Dennison]

In article <a4c0053f.0107301326.1815330c@posting.google.com>, Milan Mancel
says...
>What really puts people off Ada is that they cannot hack code like in
>C. In Ada you have to think first. You have to think of correct types

I have heard this so much from Ada newbies over the years (ones that I'm pretty
sure have *not* heard it from the others), that I begin to think there is a
large amount of truth in it. But I have to admit that I can't hear that
statement without chuckling. 

I shouldn't laugh, because it is meant seriously. But complaining about being
forced to think while programming is like complaining about being forced to
immerse yourself while swimming; it is the very nature of the task. A real
developer can no more sit down at a keyboard and just "hack" out a good program
than a real writer can just sit down at a word-processor and hack out a good
novel. I know some writers who actually formally outline their *emails* before
starting to write them. But for some reason this level of forethought is not
appreciated by the masses where software development is concerned.

>What I really miss is good and short example code of every Ada concept
>and maybe more libraries and bindings.

You can find a bit of that in AdaPower's Source Code Treasury (
http://www.adapower.com/adacode.html )

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

Re: How to make Ada a dominant language

[Gary Lisyansky]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:Joz97.12578$ar1.38154@www.newsranger.com...
> In article <a4c0053f.0107301326.1815330c@posting.google.com>, Milan Mancel

> I have heard this so much from Ada newbies over the years (ones that I'm
pretty
> sure have *not* heard it from the others), that I begin to think there is
a
> large amount of truth in it. But I have to admit that I can't hear that
> statement without chuckling.
>
> I shouldn't laugh, because it is meant seriously. But complaining about
being
> forced to think while programming is like complaining about being forced
to
> immerse yourself while swimming; it is the very nature of the task. A real
> developer can no more sit down at a keyboard and just "hack" out a good
program
> than a real writer can just sit down at a word-processor and hack out a
good
> novel. I know some writers who actually formally outline their *emails*
before
> starting to write them. But for some reason this level of forethought is
not
> appreciated by the masses where software development is concerned.
>
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

I think that good programming practices and languages designed to support
them (like Ada) don't go along well with the software process ideology
prevailing now in commercial development. Instead of comparatively
straitforward process (requirements -> specification -> design ->
implementation) it is centered around *frequent re- writing* of code and
early demonstrations of UI/features, followed by iterational re- design.
Quite frequently even the interdependancies of part of the project is
ignored, just to show something resembling a working application- usually a
part of functionality with no even error handling. To make things worse, the
customers/management tend to think that demonstrated features are *fully
implemented*, thus giving no time for clean- ups. In common, I would say
that parts of software process that don't produce user- visible results that
don't have PR value tend to be shunned.
Another trouble comes from RAD world. RAD tools created many "programmers"
who don't even understand how their applications actually work. They think
on the level of Forms and Event Handlers, i. e. have a heavily fragmented
vision of the program that doesn't allow them to see the system as a whole.
The "nec plus ultra" of this approach was one project where the schedule
listed only screen forms, with one month allocated per one, and totally no
mentioning of any application core.

Gary

Re: How to make Ada a dominant language

[Marin David Condic]

Well, there's something to be said for quickly hacking out some lines of
code in some settings. When I used to hack together DCL jobs to do some
basic file manipulations, etc., I didn't want to spend time considering data
types, flow of control, module structure, etc. So Ada could become a royal
pain-in-the-posterior if I was forced to use it for quick-and-dirty
command-line hacks.

But most software is larger and more serious. Someone complaining because
they are being forced to think before coding is obviously not doing their
job well. They are organically growing code rather than designing it. Not a
good thing when you get beyond - oh, what would you say? - a thousand SLOCs?
It doesn't take long before you'd better start thinking!

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:Joz97.12578$ar1.38154@www.newsranger.com...
> In article <a4c0053f.0107301326.1815330c@posting.google.com>, Milan Mancel
> says...
> >What really puts people off Ada is that they cannot hack code like in
> >C. In Ada you have to think first. You have to think of correct types
>
> I have heard this so much from Ada newbies over the years (ones that I'm
pretty
> sure have *not* heard it from the others), that I begin to think there is
a
> large amount of truth in it. But I have to admit that I can't hear that
> statement without chuckling.
>
> I shouldn't laugh, because it is meant seriously. But complaining about
being
> forced to think while programming is like complaining about being forced
to
> immerse yourself while swimming; it is the very nature of the task. A real
> developer can no more sit down at a keyboard and just "hack" out a good
program
> than a real writer can just sit down at a word-processor and hack out a
good
> novel. I know some writers who actually formally outline their *emails*
before
> starting to write them. But for some reason this level of forethought is
not
> appreciated by the masses where software development is concerned.
>
> >What I really miss is good and short example code of every Ada concept
> >and maybe more libraries and bindings.
>
> You can find a bit of that in AdaPower's Source Code Treasury (
> http://www.adapower.com/adacode.html )
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: How to make Ada a dominant language

[David Bolen]

Ted Dennison<dennison@telepath.com> writes:

> I shouldn't laugh, because it is meant seriously. But complaining
> about being forced to think while programming is like complaining
> about being forced to immerse yourself while swimming; it is the
> very nature of the task. A real developer can no more sit down at a
> keyboard and just "hack" out a good program than a real writer can
> just sit down at a word-processor and hack out a good novel. I know
> some writers who actually formally outline their *emails* before
> starting to write them. But for some reason this level of
> forethought is not appreciated by the masses where software
> development is concerned.

Of course, real writers certainly go through drafts and often write in
a stream-of-consciousness just to get down their thoughts, so that
might be a bit strained of an analogy.

I don't think it has to be an either/or situation - iterative,
evolutionary development (and even something like XP) has its merits
just as does a more classical, staged development (although I must
admit a bias in not being the biggest fan of strict waterfall).

I do cringe when I think of all those VB programmers (of which I am
not one, although I work with them) considering an application to be
nothing more than snippets of code associated with GUI elements, but
in some environments (hopefully small ones :-)), it can be both a
practical and efficient means to an end.  And good programs come in
all sizes, and "goodness" has many dimensions.

Note also that an evolutionary development strategy need not preclude
an overall architecture or system design, but can build on a framework
to flesh out that design over time while still producing measurable
and testable intermediate results.  Just because you're producing some
basic functionality sooner doesn't mean you aren't aiming at the same
overall design, and in fact the iterations can help prevent design
mistakes (or malformed requirements) from showing up very late in the
game.

Does that preclude a more formal approach in other cases?  Of course
not.  But I think it's crucial that a real developer today understand
more than just one approach to application design and development, and
more importantly, be able to weigh the pros and cons in the context of
any given situation.  Given the breadth of environments within which
software is used today, I don't think that one size fits all, nor that
one language fits all.  Then again, maybe that was never true :-)

--
-- 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 to make Ada a dominant language

[Ted Dennison]

In article <uzo9ksipu.fsf@ctwd0143.fitlinxx.com>, David Bolen says...
>
>I do cringe when I think of all those VB programmers (of which I am
>not one, although I work with them) considering an application to be
>nothing more than snippets of code associated with GUI elements, but

In some environments that may be accurate. But even a GUI app needs to have the
GUI *designed* before someone starts working on it. I usually use a whiteboard
for this purpose, as its quickest for erasing and redrawing.

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

Re: How to make Ada a dominant language

[David Bolen]

Ted Dennison<dennison@telepath.com> writes:

> In article <uzo9ksipu.fsf@ctwd0143.fitlinxx.com>, David Bolen says...
> >
> >I do cringe when I think of all those VB programmers (of which I am
> >not one, although I work with them) considering an application to be
> >nothing more than snippets of code associated with GUI elements, but
> 
> In some environments that may be accurate. But even a GUI app needs
> to have the GUI *designed* before someone starts working on it. I
> usually use a whiteboard for this purpose, as its quickest for
> erasing and redrawing.

That's sort of the point about the RADs nowadays though - it's pretty
common _not_ to bother designing the GUI up front, but just start
dropping controls around and then re-arranging them in the editor
until it looks ok (or for a truly quick 'n dirty test app, just
leaving them where they fall), and then associating code with them
based on what they on-the-fly think that the button or widget should
be doing.

To be honest, for really rapid, throwaway utilities, it can vastly
streamline getting something running that actually has a reasonable
GUI.  Why draw/erase on a whiteboard, when you can just add/delete the
button on the screen.  But it risks very quickly getting messy as
something gets bigger, and/or that "throwaway" thing is realized not
to be so throwable.

It's not that you can't do design up front, and I'm sure many people
do, but that the environments actually make it enticingly easy not to
bother with it, while the negative impacts are less obvious to see
until later.

--
-- 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 to make Ada a dominant language

[Milan Mancel]

Ted Dennison<dennison@telepath.com> wrote in message news:<Joz97.12578$ar1.38154@www.newsranger.com>...
> In article <a4c0053f.0107301326.1815330c@posting.google.com>, Milan Mancel
> says...
> >What really puts people off Ada is that they cannot hack code like in
> >C. In Ada you have to think first. You have to think of correct types
> 
> I have heard this so much from Ada newbies over the years (ones that I'm pretty
> sure have *not* heard it from the others), that I begin to think there is a
> large amount of truth in it. But I have to admit that I can't hear that
> statement without chuckling. 
> 
> I shouldn't laugh, because it is meant seriously. But complaining about being
> forced to think while programming is like complaining about being forced to
> immerse yourself while swimming; it is the very nature of the task. A real
> developer can no more sit down at a keyboard and just "hack" out a good program
> than a real writer can just sit down at a word-processor and hack out a good
> novel. I know some writers who actually formally outline their *emails* before
> starting to write them. But for some reason this level of forethought is not
> appreciated by the masses where software development is concerned.

I did not complain about being forced to think first, I often try to
think as hard as my lazy brain allows it. What I meant was, that this
feature of Ada will put off "programmers" who know only one language
(C, C++, ....) and use it for all programming tasks (one language
suits all) -  prototyping, testing code, "small" and "big" apps and
often do not know that writing code is the one of the final stages of
app development. I know what I am talking about - I was the same 15
years ago - I used C for everything.

Often it is necessary to quick hack few lines of code, for example few
days ago I needed to fill database with testing data of 50000 random
user profiles (each user has something about 40 attributes), I would
not do it in Java and definitely not in Ada (even if I was not only
Ada newbie). Quick hack in Python did the job. And when I was writing
this script I managed to write few classes that I find so usefull that
I will rewrite them in Java and use in final application, so I think
that evolutionary principle is not that bad :)

I think that Ada is not good for this kind of disposable code or
scripts, and I am afraid that many newbie programmers with only "one
language experience"  try to switch to Ada and not to use the right
tool for the right job.

> 
> >What I really miss is good and short example code of every Ada concept
> >and maybe more libraries and bindings.
> 
> You can find a bit of that in AdaPower's Source Code Treasury (
> http://www.adapower.com/adacode.html )


Yes, I find it very valuable source of information!

     Milan

Re: How to make Ada a dominant language

[Larry Hazel]

Milan Mancel wrote:
> 
> Ted Dennison<dennison@telepath.com> wrote in message news:<Joz97.12578$ar1.38154@www.newsranger.com>...
> > In article <a4c0053f.0107301326.1815330c@posting.google.com>, Milan Mancel
> > says...
> > >What really puts people off Ada is that they cannot hack code like in
> > >C. In Ada you have to think first. You have to think of correct types
> >
> > I have heard this so much from Ada newbies over the years (ones that I'm pretty
> > sure have *not* heard it from the others), that I begin to think there is a
> > large amount of truth in it. But I have to admit that I can't hear that
> > statement without chuckling.
> >
<snip>
> 
> Often it is necessary to quick hack few lines of code, for example few
> days ago I needed to fill database with testing data of 50000 random
> user profiles (each user has something about 40 attributes), I would
> not do it in Java and definitely not in Ada (even if I was not only
> Ada newbie). Quick hack in Python did the job. And when I was writing
> this script I managed to write few classes that I find so usefull that
> I will rewrite them in Java and use in final application, so I think
> that evolutionary principle is not that bad :)
> 
> I think that Ada is not good for this kind of disposable code or
> scripts, and I am afraid that many newbie programmers with only "one
> language experience"  try to switch to Ada and not to use the right
> tool for the right job.
> 
Some programs are small enough to be designed in your head or a few diagrams on
a couple of sheets of paper.  Once I learned Ada, I never had any problem
writing such programs in Ada.  It's quick and easy and usually does exactly what
I want the first time.  I could never do that in C, but then I don't know C very
well.  I know just enough to know I don't want to use it.  Almost any language
can be used to quickly "hack" out a small program, but you have to know the
language.

Larry

Re: How to make Ada a dominant language

[Marin David Condic]

There is also a kind of design methodology wherein you might hammer out some
code, see how it looks, maybe test it a little, then restructure it again
and again as you are trying to a) figure out how certain features should be
used and/or b) get a vision in your head as to what the ultimate product
ought to look like. Its a kind of iterative prototyping that I find myself
going through from time to time in some cases. It certainly isn't the way to
develop a major system/subsystem, but it is often handy for some kinds of
development, simply because you don't have a good idea in your head as to
how something ought to look.

That sort of development might be less concerned with proper data types,
formal design, documentation, etc., but I tend to think of that as strictly
prototype development to gain understanding. The ultimate finished product
has to be better thought out & planned - but may still utilize the
prototyped code in some form.

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 Hazel" <lhazel@mindspring.com> wrote in message
news:3B67F0DA.8D655109@mindspring.com...
> Milan Mancel wrote:
> >
> > Ted Dennison<dennison@telepath.com> wrote in message
news:<Joz97.12578$ar1.38154@www.newsranger.com>...
> > > In article <a4c0053f.0107301326.1815330c@posting.google.com>, Milan
Mancel
> > > says...
> > > >What really puts people off Ada is that they cannot hack code like in
> > > >C. In Ada you have to think first. You have to think of correct types
> > >
> > > I have heard this so much from Ada newbies over the years (ones that
I'm pretty
> > > sure have *not* heard it from the others), that I begin to think there
is a
> > > large amount of truth in it. But I have to admit that I can't hear
that
> > > statement without chuckling.
> > >
> <snip>
> >
> > Often it is necessary to quick hack few lines of code, for example few
> > days ago I needed to fill database with testing data of 50000 random
> > user profiles (each user has something about 40 attributes), I would
> > not do it in Java and definitely not in Ada (even if I was not only
> > Ada newbie). Quick hack in Python did the job. And when I was writing
> > this script I managed to write few classes that I find so usefull that
> > I will rewrite them in Java and use in final application, so I think
> > that evolutionary principle is not that bad :)
> >
> > I think that Ada is not good for this kind of disposable code or
> > scripts, and I am afraid that many newbie programmers with only "one
> > language experience"  try to switch to Ada and not to use the right
> > tool for the right job.
> >
> Some programs are small enough to be designed in your head or a few
diagrams on
> a couple of sheets of paper.  Once I learned Ada, I never had any problem
> writing such programs in Ada.  It's quick and easy and usually does
exactly what
> I want the first time.  I could never do that in C, but then I don't know
C very
> well.  I know just enough to know I don't want to use it.  Almost any
language
> can be used to quickly "hack" out a small program, but you have to know
the
> language.
>
> Larry

Re: How to make Ada a dominant language

[Larry Hazel]

Marin David Condic wrote:
> 
> There is also a kind of design methodology wherein you might hammer out some
> code, see how it looks, maybe test it a little, then restructure it again
> and again as you are trying to a) figure out how certain features should be
> used and/or b) get a vision in your head as to what the ultimate product
> ought to look like. Its a kind of iterative prototyping that I find myself
> going through from time to time in some cases. It certainly isn't the way to
> develop a major system/subsystem, but it is often handy for some kinds of
> development, simply because you don't have a good idea in your head as to
> how something ought to look.
> 
> That sort of development might be less concerned with proper data types,
> formal design, documentation, etc., but I tend to think of that as strictly
> prototype development to gain understanding. The ultimate finished product
> has to be better thought out & planned - but may still utilize the
> prototyped code in some form.

Using Ada to help think about the problem and develop a design approach.  I've
done that many times.

Larry

Re: How to make Ada a dominant language

[Marin David Condic]

I'll bet that using some version of this kind of iterative prototyping to
approaching an ultimate product is done a lot more often than many of us may
want to admit. It probably is also capable of producing good designs and
reliable products in less time than more formal methods for some classes of
problems. I doubt it is the sort of thing one would want to use to develop a
major banking network system or a complex rocket launch control system (I've
seen such things organically grown) but for some kinds of smaller, self
contained problems, this is probably a good design methodology for the
experienced developer. Lets face it - most of us think better in Ada than we
do in UML or Mil-Std-2167a documents. That, and we like to experiment with
different approaches to gain enlightment. (Think about it a little, hack a
little code, run some tests, fix some bugs, go back to step one...) We don't
generally want to draw a diagram, start writing the code, discover there is
a better way to do it and be forced to decide to either redraw the diagram
or stick with it and have a sub-optimal answer.

I'd consider the technique valid, but before declaring "Victory", I'd want
to review the prototype(s) and take a decision about using it "as is" or
using it as a model for a more robust design/implementation.

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 Hazel" <lhazel@mindspring.com> wrote in message
news:3B682658.57BE8A24@mindspring.com...
>
> Using Ada to help think about the problem and develop a design approach.
I've
> done that many times.
>

Re: How to make Ada a dominant language

[Ed Falis]

Marin David Condic wrote:
> 
> I'll bet that using some version of this kind of iterative prototyping to
> approaching an ultimate product is done a lot more often than many of us may
> want to admit. It probably is also capable of producing good designs and
> reliable products in less time than more formal methods for some classes of
> problems. I doubt it is the sort of thing one would want to use to develop a
> major banking network system or a complex rocket launch control system (I've
> seen such things organically grown) but for some kinds of smaller, self
> contained problems, this is probably a good design methodology for the
> experienced developer. Lets face it - most of us think better in Ada than we
> do in UML or Mil-Std-2167a documents. That, and we like to experiment with
> different approaches to gain enlightment. (Think about it a little, hack a
> little code, run some tests, fix some bugs, go back to step one...) We don't
> generally want to draw a diagram, start writing the code, discover there is
> a better way to do it and be forced to decide to either redraw the diagram
> or stick with it and have a sub-optimal answer.
> 
> I'd consider the technique valid, but before declaring "Victory", I'd want
> to review the prototype(s) and take a decision about using it "as is" or
> using it as a model for a more robust design/implementation.

You might want to check out "extreme programming".  It's a method that
tries to add discipline to such an iterative process by combining
various practices synergistically.  It's not intended for large programs
involving hundreds of programmers, but has been used successfully in
efforts involving 20 or less.  And AUnit, the GPL-ed unit test framework
for Ada (at adapower) supports one of the key practices of the method -
test first programming.  You can start at www.xprogramming.com

- Ed

Re: How to make Ada a dominant language

[Ted Dennison]

In article <3B67F0DA.8D655109@mindspring.com>, Larry Hazel says...
>
>a couple of sheets of paper.  Once I learned Ada, I never had any problem
>writing such programs in Ada.  It's quick and easy and usually does exactly 
>what I want the first time.  I could never do that in C, but then I don't know 
>C very well.  I know just enough to know I don't want to use it.  Almost any 
>language can be used to quickly "hack" out a small program, but you have to 
>know the language.

I'd agree with the last sentece of that, but not the stuff in the middle. I've
found that C is actually quite servicable for very small programs (eg: a one
source file, < 2000 SLOC or so mini-compiler I had to write). Its real problem
is that it just doesn't scale well at all. For a similar but larger task (eg: a
>10,000SLOC multi-file programming language compiler for a grad course) it begins to become an absolute nightmare; a veritable cornucopia of core dumps, if you will. :-)

However, there really isn't any problem with Ada for very small programs either,
and it *does* scale well.

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

Re: How to make Ada a dominant language

[Ted Dennison]

First off, I'm sorry if I implied that I thought *you* were complaining. It was
clear you were just relating how you saw others would feel.

In article <a4c0053f.0108010111.18860989@posting.google.com>, Milan Mancel
says...
>Often it is necessary to quick hack few lines of code, for example few
>days ago I needed to fill database with testing data of 50000 random
>user profiles (each user has something about 40 attributes), I would
>not do it in Java and definitely not in Ada (even if I was not only
>Ada newbie). Quick hack in Python did the job. And when I was writing
>this script I managed to write few classes that I find so usefull that
>I will rewrite them in Java and use in final application, so I think
>that evolutionary principle is not that bad :)
>
>I think that Ada is not good for this kind of disposable code or
>scripts, and I am afraid that many newbie programmers with only "one

Of course it would be silly to deny that there are some times Ada is *not* the
right tool. However, I think the example you quote is one that for me would not
be a good example. I would have no problem using Ada for something like that
(particularly if I already had the user profile data structure hanging around,
which would seem likely). I generally only use simpler tools for much simpler
tasks. For instance, it would be silly to write myself a specific file string
searching program when "grep", "find", and "xargs" are available to be used
together for that purpose. However, when I needed to write my own version of "cp
-r" due to file system problems I had to work around, Ada was where I went. When
you are comfortable enough with Ada, you will probably find yourself using it
for such tasks too. I think its really a matter of familiarity more than
anything else.

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

Re: How to make Ada a dominant language

[Scott Ingram]

Milan Mancel wrote:
> 
> I did not complain about being forced to think first, I often try to
> think as hard as my lazy brain allows it. What I meant was, that this
> feature of Ada will put off "programmers" who know only one language
> (C, C++, ....) and use it for all programming tasks (one language
> suits all) -  prototyping, testing code, "small" and "big" apps and
> often do not know that writing code is the one of the final stages of
> app development. I know what I am talking about - I was the same 15
> years ago - I used C for everything.

Oddly, with the regex and spitbol child packages in GNAT, I find
myself using other languages less and less.

> 
> Often it is necessary to quick hack few lines of code, for example few
> days ago I needed to fill database with testing data of 50000 random
> user profiles (each user has something about 40 attributes), I would
> not do it in Java and definitely not in Ada (even if I was not only
> Ada newbie). Quick hack in Python did the job. And when I was writing
> this script I managed to write few classes that I find so usefull that
> I will rewrite them in Java and use in final application, so I think
> that evolutionary principle is not that bad :)
> 
> I think that Ada is not good for this kind of disposable code or
> scripts, and I am afraid that many newbie programmers with only "one
> language experience"  try to switch to Ada and not to use the right
> tool for the right job.

Not being an Ada "newbie," this is definitely something that I would
use Ada for.  But then I have chunks of code written for many different
quick and dirties that would make this basically a simple cut and paste
for me, and relieves me of remembering all kinds of gawk, sed, and bash
incantations.  Ed Falis's mention of ruby  here in cla intrigued
me...and
it looks very promising, but I haven't spent enough time with it to do
this kind of task.  Perl and python are definitely losers here for me--
takes too long to peruse the book to figure out how to do it...:)


-- 
Scott Ingram
Vice-Chair, Baltimore SIGAda
System Development and Operational Support Group
Johns Hopkins University Applied Physics Laboratory

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <3B657715.7EC592D9@sneakemail.com>, Russ Paielli <18k11tm001@sneakemail.com> writes:
> > Larry Kilgallen wrote:
...snip...
> > I am new to Ada, and I believe that gives me a certain perspective that
> > Ada veterans lack. I am making a proposal that could save the best
> > programming language around, and all I get is a bunch of irrelevant
> > criticism.

I'm not sure the above properly attributes the correct authors.. I believe
Russ wrote the "I am new to Ada..".

To the "I am new to Ada" person:

You are sadly deluded if you think that a "python enthused" change request
to Ada is going to be accepted. Despite any reasoning that you might have,
you are not going to have people with millions of Ada lines of code accept
that now they must use new syntax. Creating a new language with the ideas
that you've presented, only takes Ada back to some of the things it purposely
steered clear of. And I'll add, that the indentation idea that Python uses,
IMHO, is definitely "not a good thing" (tm).

This news group welcomes enthusiasm, but you need to do some more homework.
After you've used and studied Ada95 for a while, then let's see what your
ideas look like. Right now, they're not well informed ideas.

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

Re: How to make Ada a dominant language

[Russ Paielli]

"Warren W. Gay VE3WWG" wrote:
> 
> Larry Kilgallen wrote:
> > In article <3B657715.7EC592D9@sneakemail.com>, Russ Paielli <18k11tm001@sneakemail.com> writes:
> > > Larry Kilgallen wrote:
> ...snip...
> > > I am new to Ada, and I believe that gives me a certain perspective that
> > > Ada veterans lack. I am making a proposal that could save the best
> > > programming language around, and all I get is a bunch of irrelevant
> > > criticism.
> 
> I'm not sure the above properly attributes the correct authors.. I believe
> Russ wrote the "I am new to Ada..".
> 
> To the "I am new to Ada" person:

That's me.

> You are sadly deluded if you think that a "python enthused" change request
> to Ada is going to be accepted. Despite any reasoning that you might have,
> you are not going to have people with millions of Ada lines of code accept
> that now they must use new syntax. Creating a new language with the ideas
> that you've presented, only takes Ada back to some of the things it purposely
> steered clear of. And I'll add, that the indentation idea that Python uses,
> IMHO, is definitely "not a good thing" (tm).

Apparently you did not read my proposal very clearly. It would not
require a single line of Ada to be rewritten, nor would it require any
Ada programmer to stop using Ada95 syntax. I may be naive, but I am not
completely clueless.

Russ

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

Russ Paielli wrote:
> "Warren W. Gay VE3WWG" wrote:
> > Larry Kilgallen wrote:
> > > In article <3B657715.7EC592D9@sneakemail.com>, Russ Paielli <18k11tm001@sneakemail.com> writes:
> > > > Larry Kilgallen wrote:
> > ...snip...
> > > > I am new to Ada, and I believe that gives me a certain perspective that
> > > > Ada veterans lack. I am making a proposal that could save the best
> > > > programming language around, and all I get is a bunch of irrelevant
> > > > criticism.
> >
> > I'm not sure the above properly attributes the correct authors.. I believe
> > Russ wrote the "I am new to Ada..".
> >
> > To the "I am new to Ada" person:
> 
> That's me.
> 
> > You are sadly deluded if you think that a "python enthused" change request
> > to Ada is going to be accepted. Despite any reasoning that you might have,
> > you are not going to have people with millions of Ada lines of code accept
> > that now they must use new syntax. Creating a new language with the ideas
> > that you've presented, only takes Ada back to some of the things it purposely
> > steered clear of. And I'll add, that the indentation idea that Python uses,
> > IMHO, is definitely "not a good thing" (tm).
> 
> Apparently you did not read my proposal very clearly. It would not
> require a single line of Ada to be rewritten, nor would it require any
> Ada programmer to stop using Ada95 syntax. I may be naive, but I am not
> completely clueless.
> 
> Russ

Then you will have read my sentence that "Creating a new language with the ideas
that you've presented, only takes Ada back to some of the things it purposely
steered clear of."  But, you selectively chose not to address that issue.

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

Re: How to make Ada a dominant language

[Pascal Obry]

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

> My proposal is deliberately designed to have a minimal effect on
> stability. As I said, a relatively simple preprocessor would be able to
> translate back and forth between Ada95 and the syntax I am proposing. If
> you want to continue to use Ada95 syntax, you could do so with impunity.
> What's the problem?
> 
> In the meantime, the Ada community seems determined to rearrange the
> chairs on the deck of the Titanic.
> 
> I read recently that only one in ten new DoD WEAPONS programs is even
> choosing Ada now that the DoD mandate has been dropped. Don't even ask
> about DoD accounting and supply-chain management programs!

Yes and that's a chance for Ada. We have more and more non-DoD use of Ada.

> 
> I am trying to sell Ada for a safety-critical program, and I am getting
> little or no support from my organization. I get forwarded email
> messages from full professors of CS at MIT claiming that Ada is being
> replaced by Java even in their studies of software reliability.

> You Ada guys seem determined to let Ada slip into oblivion. I'll bet HAL
> and Jovial programmers are proud of the stability of their languages
> too.

Certainly not. But as all of us (stupid as we are :) seems to say "your
proposal will solve just nothing". Ada low usage has certainly nothing to do
with the syntax. Another way to see that is that if the syntax is the problem
then we should certainly fix the programmers! We are talking about _software_
here not some kind of hacking to produce yet another buggy software. Fact is
Ada has been designed to be easier to read than to write. Why ? Because you
read a program many time but you write it once. The current syntax has been
_designed_ it is not the result of 1 hour work :)

> I am new to Ada, and I believe that gives me a certain perspective that
> Ada veterans lack. 

That show also that you have not grasped Ada philosophy yet! You just seems to
try to apply to Ada some kind of general recipe that you have learn using
C/C++ or Java. Please let the time give you a better understanding of Ada
underlying concept.

> I am making a proposal that could save the best
> programming language around, and all I get is a bunch of irrelevant
> criticism.

:) 

Are you serious ! You are "new to Ada", well you say so, and you are just
trying to "make a proposal" to make it the best language ! So please learn Ada
first then you'll be able to fix it.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: How to make Ada a dominant language

[Russ Paielli]

Pascal Obry wrote:
> 
> Russ Paielli <18k11tm001@sneakemail.com> writes:
> 
> > My proposal is deliberately designed to have a minimal effect on
> > stability. As I said, a relatively simple preprocessor would be able to
> > translate back and forth between Ada95 and the syntax I am proposing. If
> > you want to continue to use Ada95 syntax, you could do so with impunity.
> > What's the problem?
> >
> > In the meantime, the Ada community seems determined to rearrange the
> > chairs on the deck of the Titanic.
> >
> > I read recently that only one in ten new DoD WEAPONS programs is even
> > choosing Ada now that the DoD mandate has been dropped. Don't even ask
> > about DoD accounting and supply-chain management programs!
> 
> Yes and that's a chance for Ada. We have more and more non-DoD use of Ada.

Ya, and if DoD drops Ada completely we'll be in fabulous shape, eh?

> >
> > I am trying to sell Ada for a safety-critical program, and I am getting
> > little or no support from my organization. I get forwarded email
> > messages from full professors of CS at MIT claiming that Ada is being
> > replaced by Java even in their studies of software reliability.
> 
> > You Ada guys seem determined to let Ada slip into oblivion. I'll bet HAL
> > and Jovial programmers are proud of the stability of their languages
> > too.
> 
> Certainly not. But as all of us (stupid as we are :) seems to say "your
> proposal will solve just nothing". Ada low usage has certainly nothing to do
> with the syntax. Another way to see that is that if the syntax is the problem
> then we should certainly fix the programmers! We are talking about _software_
> here not some kind of hacking to produce yet another buggy software. Fact is
> Ada has been designed to be easier to read than to write. Why ? Because you
> read a program many time but you write it once. The current syntax has been
> _designed_ it is not the result of 1 hour work :)
> 
> > I am new to Ada, and I believe that gives me a certain perspective that
> > Ada veterans lack.
> 
> That show also that you have not grasped Ada philosophy yet! You just seems to
> try to apply to Ada some kind of general recipe that you have learn using
> C/C++ or Java. Please let the time give you a better understanding of Ada
> underlying concept.
> 
> > I am making a proposal that could save the best
> > programming language around, and all I get is a bunch of irrelevant
> > criticism.
> 
> :)
> 
> Are you serious ! You are "new to Ada", well you say so, and you are just
> trying to "make a proposal" to make it the best language ! So please learn Ada
> first then you'll be able to fix it.

I am not saying anything about Ada fundamentals. As far as I know, they
are great. That is, in fact, why I even care about the syntax. And I
don't think I need to be an expert to comment on the syntax. Ada is like
a modern car with a fabulous drivetrain and suspension, but an ugly
body. How well do you think such a car would sell? And you don't need to
be an expert to see that something is wrong.

Everyone on this thread seems to think that syntax is completely
superficial. Well, it is in a sense, but it is also the interfact that
the language presents to the programmer every working minute, and that
is important. all I am asking is, why not just get it right?

Russ

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

Russ Paielli wrote:
> Pascal Obry wrote:
> > Russ Paielli <18k11tm001@sneakemail.com> writes:
> > Are you serious ! You are "new to Ada", well you say so, and you are just
> > trying to "make a proposal" to make it the best language ! So please learn Ada
> > first then you'll be able to fix it.
> 
> I am not saying anything about Ada fundamentals. As far as I know, they
> are great. That is, in fact, why I even care about the syntax. And I
> don't think I need to be an expert to comment on the syntax. Ada is like
> a modern car with a fabulous drivetrain and suspension, but an ugly
> body. How well do you think such a car would sell? And you don't need to
> be an expert to see that something is wrong.
> 
> Everyone on this thread seems to think that syntax is completely
> superficial. Well, it is in a sense, but it is also the interfact that
> the language presents to the programmer every working minute, and that
> is important. all I am asking is, why not just get it right?
> 
> Russ

Russ, the Jeep is a vehicle with excellent drive train, but is has an
ugly body (of course beauty is in the eye of...). Yet, Jeeps are very
popular now.... so much for that analogy. ;-)

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

Re: How to make Ada a dominant language

[Pascal Obry]

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

> Everyone on this thread seems to think that syntax is completely
> superficial. Well, it is in a sense, but it is also the interfact that
> the language presents to the programmer every working minute, and that
> is important. all I am asking is, why not just get it right?

Because we all (almost maybe) thinks in this NG that Ada is right. Ada is
a standard and well designed modern language. The important aspect of it is
not the syntax which is quite good as we all think. Be patient, try it one
more year, you'll will love the way it is designed: building blocks. Every
single piece of the language mix very well with any others and it has an
expressive power that not many language can offer you.

Again, bear in mind that Ada has been designed by very competent peoples so
before changing anything ask yourself: Well this seems wrong to me maybe I'm
missing something :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: How to make Ada a dominant language

[Marin David Condic]

Why are you so convinced that Ada got it wrong? I've been using Ada since
way-back-when (I used to have standards for "Ada-80" on my shelf -
preliminary drafts before the final standard of Ada-83 came out.) and
thought it was an imense improvement in syntax over numerous other languages
I had used. It avoided lots of common syntax traps that existed in languages
like Cobol and Pascal and C - syntax traps you are proposing to put back in.
The syntax was aimed at making things as easy to read as possible so that
maintenance effort would be eased, and I think it succeeded at that very
well.

The syntax may not be what you are used to, but I really don't see that it
is in any way "broken". It achieves its goals of high readability and avoids
a number of pitfalls that would make it difficult for a parser to identify
where errors occur because of simple typos. I'd bet that by the time you've
written a couple of megabytes of Ada code, you'll be used to the syntax and
it will roll off your tongue very naturally. You won't find it nearly so
"broken" then as you may now - in fact you may even gain some insight into
*why* certain choices were made for syntax and how nicely "orthogonal" the
syntax is.

Or you can try writing a preprocessor to change the syntax and maybe you'll
come up with a language hugely more popular than Ada. I invite you to do so.
If Ada'Succ becomes hugely popular with a different syntax, I'll gladly
learn the different syntax and move on - just as I've done with dozens of
other languages. Syntax may be important to appearance, popularity,
readability, error avoidance, etc., but I don't think this is the big driver
as far as popularity goes. Semantics are much more an issue.

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/


"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B662A07.966963CF@sneakemail.com...
>
> Everyone on this thread seems to think that syntax is completely
> superficial. Well, it is in a sense, but it is also the interfact that
> the language presents to the programmer every working minute, and that
> is important. all I am asking is, why not just get it right?
>

Re: How to make Ada a dominant language

[Brian Rogoff]

On Mon, 30 Jul 2001, Russ Paielli wrote:
> Larry Kilgallen wrote:
> > 
> > One of the best things about Ada is stability. There have only been two
> > versions of the standard, and vendor extensions are well under control.
> 
> > There are many things that can be done to make Ada more popular outside
> > the language definition.  Any changes to the language pale by comparison
> > in their effect.  Making Ada more popular would not be desireable if it
> > hurt the clarity and correctness advantages Ada has now.
> 
> My proposal is deliberately designed to have a minimal effect on
> stability. As I said, a relatively simple preprocessor would be able to
> translate back and forth between Ada95 and the syntax I am proposing. If
> you want to continue to use Ada95 syntax, you could do so with impunity.
> What's the problem?

You'd split the Ada community into two camps (one of which I imagine would
be very very small :) just to make Ada look like another relatively
unpopular language. 

Personally, I much prefer ":=" to "=" for assignment. OTOH, getting rid of 
":=" for constant declarations would be an (minor) improvement. More
important would be to add the C influenced Icon operators like +:=, -:=, 
*:=, etc. Anyhow, assignment should stick out, and it is not symmetric. 

I proposed before that an Ada like language with superficial C like syntax 
wouldn't be so bad either (well, really I was just following through on
Bob Duff's tongue-in-cheek proposal) and that would have the advantage of 
making Ada look like a popular (compared to Python) family of languages. 
I fully acknowledge that it was mostly a thought exercise for a new
language. Ada syntax ain't gonna change that much!

> In the meantime, the Ada community seems determined to rearrange the
> chairs on the deck of the Titanic.

I would consider your new surface syntax an activity of the same kind :-). 

I'd rather see some semantic enhancements (downward funargs, multiple
interface inheritance, withing problem fixed, ...) and leave the
syntax alone. 

> I read recently that only one in ten new DoD WEAPONS programs is even
> choosing Ada now that the DoD mandate has been dropped. Don't even ask
> about DoD accounting and supply-chain management programs!

I have more faith in the open source community than in the DoD. 

> I am trying to sell Ada for a safety-critical program, and I am getting
> little or no support from my organization. I get forwarded email
> messages from full professors of CS at MIT claiming that Ada is being
> replaced by Java even in their studies of software reliability.

Nothing against the tute (course 18, '86), but it has never been very Ada 
friendly. 

Selling a particular language that is not "mainstream" is tough in a
commercial environment. Changing the syntax of Ada would make that job
harder. 

> You Ada guys seem determined to let Ada slip into oblivion. I'll bet HAL
> and Jovial programmers are proud of the stability of their languages
> too.

C programmers value the stability of C as well, thanks. And for those of
us who can tolerate rapidly evolving languages, there are far more
interesting contestants than Python (www.ocaml.org, www.haskell.org, ...). 

> I am new to Ada, and I believe that gives me a certain perspective that
> Ada veterans lack. 

That's true. Do you also acknowledge that people with more experience may
have a certain perspective that you lack? 

> I am making a proposal that could save the best programming language
> around, and all I get is a bunch of irrelevant criticism.

No such thing as "the best programming language". The criticism isn't
really all irrelevant, either. IMO, if you want to make Ada more
successful just write tools that you want (in Ada of course) and make the 
source available under some open source license. It's just a question of 
making the activation energy for choosing Ada low enough... 

-- Brian

Re: How to make Ada a dominant language

[Russ Paielli]

Brian Rogoff wrote:
> 
> On Mon, 30 Jul 2001, Russ Paielli wrote:
> > Larry Kilgallen wrote:
> > >
> > > One of the best things about Ada is stability. There have only been two
> > > versions of the standard, and vendor extensions are well under control.
> >
> > > There are many things that can be done to make Ada more popular outside
> > > the language definition.  Any changes to the language pale by comparison
> > > in their effect.  Making Ada more popular would not be desireable if it
> > > hurt the clarity and correctness advantages Ada has now.
> >
> > My proposal is deliberately designed to have a minimal effect on
> > stability. As I said, a relatively simple preprocessor would be able to
> > translate back and forth between Ada95 and the syntax I am proposing. If
> > you want to continue to use Ada95 syntax, you could do so with impunity.
> > What's the problem?
> 
> You'd split the Ada community into two camps (one of which I imagine would
> be very very small :) just to make Ada look like another relatively
> unpopular language.

If you're not careful, they may both become small :-)

> Personally, I much prefer ":=" to "=" for assignment. OTOH, getting rid of
> ":=" for constant declarations would be an (minor) improvement. More
> important would be to add the C influenced Icon operators like +:=, -:=,
> *:=, etc. Anyhow, assignment should stick out, and it is not symmetric.

I bet you'd really love "$=". And "#$%^&*=" probably really looks great
to you. ;')

> I proposed before that an Ada like language with superficial C like syntax
> wouldn't be so bad either (well, really I was just following through on
> Bob Duff's tongue-in-cheek proposal) and that would have the advantage of
> making Ada look like a popular (compared to Python) family of languages.
> I fully acknowledge that it was mostly a thought exercise for a new
> language. Ada syntax ain't gonna change that much!
> 
> > In the meantime, the Ada community seems determined to rearrange the
> > chairs on the deck of the Titanic.
> 
> I would consider your new surface syntax an activity of the same kind :-).

I figured you would, but I think you and just about everyone else on
this thread is missing an important point. Yes, syntax is superficial in
the sense that it doesn't affect the fundamental structure of the
language, but it is important in determining the elegance of the
language. Ever heard the expression, "the first impression is the most
important"? Well, the first impression people get of a programming
language is based largely on the syntax. I'll bet a lot of programmers
are unconsciously biased one way or the other about a programming
language based simply on their initial reaction to the syntax.

> I'd rather see some semantic enhancements (downward funargs, multiple
> interface inheritance, withing problem fixed, ...) and leave the
> syntax alone.
> 
> > I read recently that only one in ten new DoD WEAPONS programs is even
> > choosing Ada now that the DoD mandate has been dropped. Don't even ask
> > about DoD accounting and supply-chain management programs!
> 
> I have more faith in the open source community than in the DoD.

The DoD controls a huge arsenal of nuclear, biological, chemical, and
conventional weapons. We had better all hope they don't have buggy
software!

> > I am trying to sell Ada for a safety-critical program, and I am getting
> > little or no support from my organization. I get forwarded email
> > messages from full professors of CS at MIT claiming that Ada is being
> > replaced by Java even in their studies of software reliability.
> 
> Nothing against the tute (course 18, '86), but it has never been very Ada
> friendly.
> 
> Selling a particular language that is not "mainstream" is tough in a
> commercial environment. Changing the syntax of Ada would make that job
> harder.

I disagree.

> > You Ada guys seem determined to let Ada slip into oblivion. I'll bet HAL
> > and Jovial programmers are proud of the stability of their languages
> > too.
> 
> C programmers value the stability of C as well, thanks. And for those of
> us who can tolerate rapidly evolving languages, there are far more
> interesting contestants than Python (www.ocaml.org, www.haskell.org, ...).
> 
> > I am new to Ada, and I believe that gives me a certain perspective that
> > Ada veterans lack.
> 
> That's true. Do you also acknowledge that people with more experience may
> have a certain perspective that you lack?

Of course I do. I have no doubt they know more about Ada than I do, but
I also have no doubt that they have unwittingly conditioned themselves
to overlook the cosmetic warts of the language.

> > I am making a proposal that could save the best programming language
> > around, and all I get is a bunch of irrelevant criticism.
> 
> No such thing as "the best programming language". The criticism isn't
> really all irrelevant, either. IMO, if you want to make Ada more
> successful just write tools that you want (in Ada of course) and make the
> source available under some open source license. It's just a question of
> making the activation energy for choosing Ada low enough...

Good luck, but you may have even more of an uphill battle than I have.
:')

Russ

Re: How to make Ada a dominant language

[Brian Rogoff]

On Mon, 30 Jul 2001, Russ Paielli wrote:
> Brian Rogoff wrote:
> > On Mon, 30 Jul 2001, Russ Paielli wrote:
> > > I am new to Ada, and I believe that gives me a certain perspective that
> > > Ada veterans lack.
> > 
> > That's true. Do you also acknowledge that people with more experience may
> > have a certain perspective that you lack?
> 
> Of course I do. I have no doubt they know more about Ada than I do, but
> I also have no doubt that they have unwittingly conditioned themselves
> to overlook the cosmetic warts of the language.

That's a profoundly stupid statement. Using a similar argument, any expert
opinion is now rendered inferior to that of a newbie!

I suspect I know Ada better than you do right now. Believe it ot not, I
also know several other languages, some of which I consider better than
Ada for certain tasks. The other languages have different syntaxes than 
Ada, some are popular, some not. I'm not hopelessly enamored of Ada
syntax, as you seem to think all Ada programmers are. Stop assuming other 
people are somehow broken, and *listen* to why they disagree with you. 

Python didn't get successful on account of its syntax, but mainly (IMO of 
course) because Perl is so especially ugly that a large group of script 
users was ready to jump on practically anything useful, and Python was 
there "firstest with the mostest". Icon was certainly before Python, but 
it lacked a really useful system interface. Ruby is also becoming popular; 
maybe it will pass Python one day. Who knows? 

> > No such thing as "the best programming language". The criticism isn't
> > really all irrelevant, either. IMO, if you want to make Ada more
> > successful just write tools that you want (in Ada of course) and make the
> > source available under some open source license. It's just a question of
> > making the activation energy for choosing Ada low enough...
> 
> Good luck, but you may have even more of an uphill battle than I have.
> :')

No, Ada is slowly becoming a bit more popular, and more code is open
sourced. So there is a very slight chance that in a few years (5-7?) 
Ada will achieve sufficient (for me :) popularity outside of the DoD. 

Yours quest is quixotic, to say the least. Have fun doing battle with
those giants! ;-)

-- Brian

Re: How to make Ada a dominant language

[file13]

> I am new to Ada, and I believe that gives me a certain perspective that
> Ada veterans lack. I am making a proposal that could save the best
> programming language around, and all I get is a bunch of irrelevant
> criticism.

i'm also fairly new to Ada (within this year) and i love both Python
and Ada.  i understand what you're saying and i agree that
syntactically, Python does have features that fit Ada's
spirit--enforcing good style.  but i simply don't agree that Ada's
lack of popularity has anything to do with its syntax.  (in fact as a
former C/Perl junkie, i LIKE Ada's syntax and think using := for
assignment is much clearer and using = for equality makes more sense
to me and avoids the easy == error.)  but the popularity of
programming languages, like anything else, is based on money.  how
many people think Java would be as popular as it is if Sun didn't pump
millions into promoting it?  since we don't have Sun's deep pockets,
it seems that we would need to start a new grassroots revolution by
promoting Ada to the new hacker culture.

now as a young Ada programmer who is working to promote Ada by writing
open source software in Ada (http://sourceforge.net/projects/fu-scan/)
i think that bringing attention to Ada is more important then changing
the language.  i believe that if Ada is to become popular among the
hacker culture, it must be promoted to the kids who have never heard
of it.  most of them have never even heard of Ada and think that
programming begins with C++ and ends with Java--or worse VB.  they are
simply unaware that Ada is powerful, fast, easy to learn, easy to
main, easy to debug, and thanks to GNAT, open source--"really, you
don't have to pay Bill to use this language."  the reason they think
they need to learn C/C++ is because they don't know about other
languages.  i used to be one of those people who thought that C++ was
the greatest thing since sliced bread and pretty much the only "REAL"
compiled language.  but then out of pure chance, i discovered Ada and
instantly feel in love with it.  i think if younger programmer knew
the advantages of Ada and saw more open source software written in Ada
they would be more inclined to check it out.

ignorance of Ada aside, i also think that languages like Python
actually help bring people to Ada by promoting the KISS
philosophy--keep it simple stupid!--and good program design.  this
KISS principle is what brought me to Python in the first place.  since
i liked this philosophy in Python, i was even more drawn to Ada once
it was brought to my attention.

another thing that i think would help would bring Ada to new people
would be a good IDE--another thread on this.....  yes, Aionix does
have a Visual Studio like IDE and windows has Adagide, but i mean a
portable open source solution.  imagine integrating Ada95 support into
kdevelop for instance?  http://www.kdevelop.org/  imagine kdevelop
being portable to windows....  i personally don't care for IDE's
myself--xemacs or death--but most of your new programmers think that
to compile a program you push "compile."  i think that if they had a
preety IDE which took care of this for them, Ada would be more
attractive.

finally, i think that we need to play up Ada's "bondage and
discipline" reputation and start dressing Lovelace up in fetish gear
if we want to draw a lot of people to Ada.....  ;)

--
file13
http://haxor.redcommandos.com/~file13/
--
"...war is about killing people and destroying things...that
requirement is...best met through the use of Ada."
Lt. Col. John A. Hamilton Jr. U.S. Military Academy
http://www.stsc.hill.af.mil/crosstalk/1997/dec/languages.asp

Re: How to make Ada a dominant language

[Ted Dennison]

In article <28d8936a.0107300951.5ae5cce@posting.google.com>, file13 says...
>finally, i think that we need to play up Ada's "bondage and
>discipline" reputation and start dressing Lovelace up in fetish gear
>if we want to draw a lot of people to Ada.....  ;)

:-)

An intersting idea...but I suspect the countess' heirs would grow to regret the
decision to allow the language to be named after her, were we to seriously
persue this course. :-)

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

Attributes of a development which require Ada (Was Re: How to make Ada a dominant language)

[Hambut]

Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B657715.7EC592D9@sneakemail.com>...
<snip>

> I am trying to sell Ada for a safety-critical program, and I am getting
> little or no support from my organization. 

This is sad to hear.  For the safety-critical problem domain I would
have expected this would be a relatively easy sell.

Anyway this got me to thinking 'What attributes of a development most
forcefully require the use of Ada?' (if this sentence makes any sense
- typically it's late at night)

The bottom line of my thinking is:
1.  Will using Ada make the developers life sufficiently easy that the
cost of training and tooling up is worth it?
2.  Are the verification requirements of the application such that Ada is
the only language with the appropriate tool support to be able to meet
the requirements?

The longer version of these points are:

<If you don't want to read these paragraphs below - fine, but there is a
final question at the very bottom........>

1. Simplification of Developers Life
------------------------------------

I can point to two (kind of) non-technical things that have pushed the
use of Ada on recalcitrant managers, in my experience:
o  Requirements of standards - The developer is forced to use Ada
because of the standards that are contractually applied.
o  Perceived requirements of regulators - Ada is chosen because the
developer believes they will get a bigger 'credit' at certification
from the regulator.

So a developer will adopt Ada if the Developer believes it will make their
(contractual) life easier.  Is this likely to be true for your
development?  Is there an independent safety organisation that would
very much prefer to see the application developed in Ada?


2. Verification Requirements
----------------------------

From a technical point of view I think that the most convincing
drivers for the use of Ada are the verification requirements.  In
other words how much testing and software analysis do you have to do?
The more you have to do the more attractive Ada becomes.  Particularly
if it's necessary to *demonstrate* very high levels of assurance in
certain properties of the final application (for example absence of
run time errors).

Demonstration of high assurance would probably entail, in addition to
high levels of testing, both a lot of very deep thought about the
software and high levels of software static analysis, for example deep
flow static analysis.

Currently I believe that Ada is the only language to cost effectively
support high levels of software static analysis.

I'm probably not saying this too well.  What I'm trying to get at is
that Ada has probably the most cost effective toolset for doing things
like:
o  Showing that all variables are initialised before use
o  Proving absence of run time errors
o  Program proving against a formal specification

So if you're application absolutely must never experience a run time
error (e.g. Nuclear Power Plant Protection Systems?) then there may be
a very good argument for the use of Ada based on the rigour of
verification that's required.

(Additionally ASIS looks like it will provide an excellent tool to do
other analyses.)

>I get forwarded email
> messages from full professors of CS at MIT claiming that Ada is being
> replaced by Java even in their studies of software reliability.

I would be very interested if you have publicly accessible
examples of such studies.

Cheers,

Hambut

Re: How to make Ada a dominant language

[Gary Lisyansky]

"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B657715.7EC592D9@sneakemail.com...
>
> I am trying to sell Ada for a safety-critical program, and I am getting
> little or no support from my organization. I get forwarded email
> messages from full professors of CS at MIT claiming that Ada is being
> replaced by Java even in their studies of software reliability.
>
They'll learn what software reliability is all about when they'll switch
from Ada to Java. But it'll be too late.

Gary

Re: How to make Ada a dominant language

[Philip Anderson]

Gary Lisyansky wrote:
> 
<snip>
> Dubious. In reality, only C/C++/Java use this "type first" order in
> declarations. Pascal uses Ada- like syntax, VB uses even more verbose
> construct (Dim Count As Integer) and so on. I've never heard anyone complain
> about "var name first" declaration convention.

CORAL 66 had the type first, and I had to get used to the Ada syntax; I
must say that now I do prefer it, because it is easier to just pick out
the variable and constant names on a first reading, whereas the type is
more of an implementation detail.

It's not a big deal, Ada had to choose one way or the other, but it is
not worth changing Ada now; having two different forms of Ada, one
requiring pre-processing to convert it into the other, must be a
non-starter - in "Day : Date", which would be the type, without looking
for a pre-processor request?  (French keywords give no such ambiguity)


For myself, I don't think that syntax differences have much effect on
the ease of learning a new language; any two languages will be different
here, but there will also be much more significant differences - for
Ada, user-defined types, the procedure/function distinction, no need to
use pointers etc.

It's the same with natural languages; changing the syntax of French to
match English would not really encourage more English speakers to learn
French.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: How to make Ada a dominant language

[Lutz Donnerhacke]

* Philip Anderson wrote:
>requiring pre-processing to convert it into the other, must be a
>non-starter - in "Day : Date", which would be the type, without looking
>for a pre-processor request?  (French keywords give no such ambiguity)

What's more readable?

    arr : array (arg'Range) of arg'Base_Type :=
                    arg (arg'First + 1 .. arg'Last, Arg'First);

or 
    array (arg'Range) of arg'Base_Type : arr :=
                    arg (arg'First + 1 .. arg'Last, Arg'First);

?

How about

    struct {
      unsigned int i7 : 7;
      unsigned int i1 : 1;
      char str [77][33];
    } var [77];

vs.
    type uint_7 is range 0 .. 2**7-1;
    
    type var_type is record
       i1 : boolean;
       i7 : uint_7;
       str : array (0 .. 33) of array (0 .. 77) of character;
    end record;
    
    for var_type use record
       i1 at 0 range 0 .. 0;
       i7 at 0 range 1 .. 7;
    end record;
    for var_type'Bit_Order use High_Order_First;
    
    var : array (0 .. 77) of var_type;

?

Re: How to make Ada a dominant language

[Barry Kelly]

In article <9k3l9r$10i2$1@pa.aaanet.ru>
	"Gary Lisyansky" <gary_the_fox@richmond.com> wrote:

> Pascal uses Ada- like syntax,

Wrong. Ada uses Pascal-like syntax.

> > > 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 "%="?
> 
> It's a change for the sake of change. It doesn't eliminate any serious
> verbosity. ":=" is simply traditional.

"=" for assignment is mathematically meaningless. What mathematician
in their right minds would write

 i = i + 1

?


-- Barry

-- 
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re: How to make Ada a dominant language

[Keith Thompson]

Barry Kelly <dynagen@eircom.net> writes:
> In article <9k3l9r$10i2$1@pa.aaanet.ru>
> 	"Gary Lisyansky" <gary_the_fox@richmond.com> wrote:
> 
> > Pascal uses Ada- like syntax,
> 
> Wrong. Ada uses Pascal-like syntax.

Well, actually both statements are correct; the first doesn't
*necessarily* imply ordering.  Someone familiar with Ada encountering
Pascal for the first time would quite naturally say that Pascal uses
Ada-like syntax (but where did these crazy semicolon rules come
from??).

> "=" for assignment is mathematically meaningless. What mathematician
> in their right minds would write
> 
>  i = i + 1
> 
> ?

One who's writing a C or Fortran program.

-- 
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 to make Ada a dominant language

[Gary Lisyansky]

"Barry Kelly" <dynagen@eircom.net> wrote in message
news:3j6jmtchpgju4l9sj0qbi011nbahre2gbo@4ax.com...
> In article <9k3l9r$10i2$1@pa.aaanet.ru>
> "Gary Lisyansky" <gary_the_fox@richmond.com> wrote:
>
> > Pascal uses Ada- like syntax,
>
> Wrong. Ada uses Pascal-like syntax.
>
Wrong. Both two use Algol- like syntax.

Gary

Re: How to make Ada a dominant language

[David Thompson]

Gary Lisyansky <gary_the_fox@richmond.com> wrote :
[ Ada vs C&friends declaration syntax ]
> Dubious. In reality, only C/C++/Java use this "type first" order in
> declarations. Pascal uses Ada- like syntax, VB uses even more verbose
> construct (Dim Count As Integer) and so on. I've never heard anyone complain
> about "var name first" declaration convention.
>
C declarations are actually "type outside" (identifier
"in the middle", aka "declaration follows use");
the canonical example is the Unix/POSIX "signal"
API, a function which takes an int and a pointer to
function of int returning void and returns a pointer
to function of int returning void:
  void (*signal(int, void (*)(int)))(int)
This reduces to "type first" only for types defined
entirely by specifiers and pointer (or C++ reference)
declarators (although mixing the latter is bugprone).
C++ is technically the same, but encourages
greater use of named and instantiated (template)
types, which fall into the "specifiers only" case
along with (in both languages) primitive types.
In C the contents of a struct (or union or enum)
follow the tag (if used) but precede the object
and/or typedef name(s); C++ is again technically
the same, with classes slightly modifying structs,
but encourages use of the tag only.

algol is the only language I know of which consistently
puts a complete type description before the identifier,
though it also allows alternative sugar for routines,
as do all(?) other languages that even have routine/
function/subprogram/etc. types to begin with.
Java allows either the C/C++ syntax or a swapped
(but not algolish) one for array, a syntax almost like
C++ for classes, no other data type derivation, and
method (routine) syntax like C/C++ prototypes.

Original FORTRAN split its limited type information
much like C; modern Fortran (F90,F95) moves more
of the type information to the left, except for structures
and subprogram "interface" declarations.
COBOL and PL/1 put all type information to the right
_except_ structure nesting "levels".  Ada and the
Pascal family (as stated) put full type information
to the right, and LISP does so if declarations are
used at all (they are (almost?) always optional).

Personally I prefer the Ada syntax, although I think
Fortran syntax can be fine for the sort of applications
that language is best suited to; and I agree that it
certainly shouldn't be a big deal either way.

--
- David.Thompson 1 now at worldnet.att.net

Re: How to make Ada a dominant language

[Stefan Nobis]

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. And
> that's part of the reason that nine out of ten programmers (or whatever)
> are non-Ada-programmers.

No, that's not the problem. =/==, block-building per indentation, type
var-name or :=/=, begin/end, var-name type is just a matter of taste. It
doesn't make programs easier or less easy to read. If a programmer has
problems with one way, he should surely think about another job.

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

Why is this so important? "=" is also the simplest symbol for comparing, so
what? If you write code with many comparisons but few assignments, Ada would
do great. :)

In the above cases (=, indentation, type var-name) Python has different syntax
than Ada. That's nice, i like Python's syntax. But what matter's really? Not
this syntactic details but all the rest of the language.

Why is Python so popular? Because it's simple and easy to learn, because it's
not statically typed (-> easier to learn).

The syntax of programming languages are never "natural" because they are no
natural languages, they are in the best case an abbreviation of natural
languages.

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

No, the changes makes programs as readable as the actual syntax is.

-- 
Until the next mail...,
Stefan.

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6555ED.9B0B0420@sneakemail.com>...
> 
> 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 "%="?

"=" means equal. "IF A = 0 THEN" reads as "if A equals 0 then" and
":=" means assignment.


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

Honestly, if you think Ada already has excellent fundamentals, why
border a change?


Adrian Hoe

Re: How to make Ada a dominant language

[Russ Paielli]

Adrian Hoe wrote:
> 
> Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6555ED.9B0B0420@sneakemail.com>...
> >
> > 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 "%="?
> 
> "=" means equal. "IF A = 0 THEN" reads as "if A equals 0 then" and
> ":=" means assignment.

But "x = 4" means that, immediately after the statement is executed, x
indeed equals 4. I don't see a problem with using "=" for both
assignment AND equality testing (am I missing something?). In Python,
the classic C problem of using "=" when you mean "==" is avoided by
simply not allowing assignment within an if test. Seems like a simple
solution to me. In Ada, the compiler would tell you if you get it wrong.

> > 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.
> 
> Honestly, if you think Ada already has excellent fundamentals, why
> border a change?

Because I'd like to have a language that has both excellent fundamentals
AND a clear, minimal syntax. I want it all. And I'm a compulsive
minimalist, I guess. It bothers me to see ":=" when "=" will do the job,
because it's not minimal. I'm also a fricking perfectionist--just ask my
wife. :-)

Russ

Re: How to make Ada a dominant language

[Martin Dowie]

Russ Paielli <18k11tm001@sneakemail.com> wrote in message
news:3B6624E6.DF734E5C@sneakemail.com...
> But "x = 4" means that, immediately after the statement is executed, x
> indeed equals 4. I don't see a problem with using "=" for both

so what does "X = X + 1" mean? This was part of the reason
why ":=" has been used in many languages (before Ada was ever
conceived).

Re: How to make Ada a dominant language

[Russ Paielli]

Martin Dowie wrote:
> 
> Russ Paielli <18k11tm001@sneakemail.com> wrote in message
> news:3B6624E6.DF734E5C@sneakemail.com...
> > But "x = 4" means that, immediately after the statement is executed, x
> > indeed equals 4. I don't see a problem with using "=" for both
> 
> so what does "X = X + 1" mean? This was part of the reason
> why ":=" has been used in many languages (before Ada was ever
> conceived).

Actually, I like the C way of writing this: "x += 1". It's a minimal
form. It's much cleaner if the variable name is long. I think C got this
one right.

Russ

Re: How to make Ada a dominant language

[Gary Lisyansky]

"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B665A01.54315D0C@sneakemail.com...
> Martin Dowie wrote:
> >
> > Russ Paielli <18k11tm001@sneakemail.com> wrote in message
> > news:3B6624E6.DF734E5C@sneakemail.com...
> > > But "x = 4" means that, immediately after the statement is executed, x
> > > indeed equals 4. I don't see a problem with using "=" for both
> >
> > so what does "X = X + 1" mean? This was part of the reason
> > why ":=" has been used in many languages (before Ada was ever
> > conceived).
>
> Actually, I like the C way of writing this: "x += 1". It's a minimal
> form. It's much cleaner if the variable name is long. I think C got this
> one right.
>
In Pascal, there's another convenient shortcut: INC(X, Y) is equivalent to X
:= X + Y and INC(X) to INC(X, 1). Both things can be implemented in Ada
using generics, so there's no real need to make them an element of syntax.

Gary

> Russ

Re: How to make Ada a dominant language

[Keith Thompson]

Russ Paielli <18k11tm001@sneakemail.com> writes:
> Martin Dowie wrote:
> > 
> > Russ Paielli <18k11tm001@sneakemail.com> wrote in message
> > news:3B6624E6.DF734E5C@sneakemail.com...
> > > But "x = 4" means that, immediately after the statement is executed, x
> > > indeed equals 4. I don't see a problem with using "=" for both
> > 
> > so what does "X = X + 1" mean? This was part of the reason
> > why ":=" has been used in many languages (before Ada was ever
> > conceived).
> 
> Actually, I like the C way of writing this: "x += 1". It's a minimal
> form. It's much cleaner if the variable name is long. I think C got this
> one right.

But "x = x + 1" is also perfectly valid C.

For that matter, "x = foo(x)" and "x = x->next" are also valid C, and
there are no corresponding compound assignment operators for these
operations.

-- 
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 to make Ada a dominant language

[Martin Dowie]

Kind of missed the point (just a little :-), The '1' could
as easily be replaced by 'Y', my fault for not choosing a
clearer example.

"X = 4" has a specific mathematical meaning, "X == 4" does not
(or at least non that I'm aware of).

Ada (and others) uses "X = 4" in the same way as the mathematical
meaning, i.e. "is equivalent to" not "is assigned to".

I don't particularly like the "+=" style, it seem counter
intuitive that this aids readability.

Our job is to code, not encode.


Russ Paielli <18k11tm001@sneakemail.com> wrote in message
news:3B665A01.54315D0C@sneakemail.com...
> Martin Dowie wrote:
> >
> > Russ Paielli <18k11tm001@sneakemail.com> wrote in message
> > news:3B6624E6.DF734E5C@sneakemail.com...
> > > But "x = 4" means that, immediately after the statement is executed, x
> > > indeed equals 4. I don't see a problem with using "=" for both
> >
> > so what does "X = X + 1" mean? This was part of the reason
> > why ":=" has been used in many languages (before Ada was ever
> > conceived).
>
> Actually, I like the C way of writing this: "x += 1". It's a minimal
> form. It's much cleaner if the variable name is long. I think C got this
> one right.

Re: How to make Ada a dominant language

[Ted Dennison]

In article <3b66520b@pull.gecm.com>, Martin Dowie says...
>
>Russ Paielli <18k11tm001@sneakemail.com> wrote in message
>news:3B6624E6.DF734E5C@sneakemail.com...
>> But "x = 4" means that, immediately after the statement is executed, x
>> indeed equals 4. I don't see a problem with using "=" for both
>
>so what does "X = X + 1" mean? This was part of the reason
>why ":=" has been used in many languages (before Ada was ever
>conceived).

This isn't an issue to gloss over either. It causes serious problems with people
who have a good foundation in math, but are just learning programming. The fact
of the matter is that an assignment is *not* a statement of assertion of
equality, as one would normally see "=" used for in any mathematical text. It is
a statement of a single replacement of value (often denoted with a left-pointing
arrow in math texts). Unless we can convince mathematicians to change the symbol
that they have been using for assertions of equality for the last 1000 years or
so (good luck over in sci.math on that one!), to aviod confusion we should
probably use it in our programming languages for the same purpose, and not for
other purposes (like assignment).

Note that Ada was perhaps the most carefully designed programming language ever.
Just about everything in the language has a good reason for the way it is, and
most of these reasons have been widely published. Thus any attempt to claim that
Ada syntax is somehow badly-thought out is quite liable to find you on the wrong
end of quite a lot of reasearch. C, for all its good qualities, was just not
carefully designed. You may be able to think up rationales to convince yourself
that C's syntax is better in some circumstances. But if you try to seriously
argue them *here*, you are bringing a knife to a gunfight. :-)

It is true that the syntax is not C's, and that may be a Bad Thing to those used
to C (and no other style of syntax), but that's pretty much where the complaint
has to stop.

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

Re: How to make Ada a dominant language

[David Gillon]

Russ Paielli wrote:

> I don't see a problem with using "=" for both
> assignment AND equality testing (am I missing something?). 

It would seem so. Assignment and Equality are not equivalent and Ada is
very specifically designed to be unambiguous when read, therefore
different symbols are required. If you're pushing Ada for safety
critical use then the features which enhance unambiguous readability
should be seen as co-equal in importance with the other safety-enhancing
features of the language.

> In Python,
> the classic C problem of using "=" when you mean "==" is avoided by
> simply not allowing assignment within an if test. Seems like a simple
> solution to me. In Ada, the compiler would tell you if you get it wrong.

Yes, but if you overload '=' for both assignment and equality then you
would still need to mentally disambiguate the operation every time you
read what was on the page. Ada's write-once, read-many philosophy means
this is 'a bad thing' (tm).

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

I think that what concerns me most about this is the implication that
the average coder out there has had so little exposure to alternate
syntax that they're unable to cope with anything that isn't C/C++ like.
Every language has syntactic quirks, some shared with other related
languages. Arguably there are three big syntactic families-- Basics,
Ada/Pascal/Delphi/Modula and C/C++ -- along with a bunch of more
individualistic types (Prolog, Lisp, APL) and if comp sci degrees aren't
making sure their graduates can cope with even the most common
variations in syntax I find that a worrying development (hell, my degree
even had a lecture on APL's syntax...).

> Because I'd like to have a language that has both excellent fundamentals
> AND a clear, minimal syntax.

Ada's syntax was specifically designed to be unabmbiguous when read. In
certain circumstances that will mean it uses more characters to do the
job than other, less safe languages. This isn't a weakness, it's
recognised as a strength by the Ada community.

> And I'm a compulsive
> minimalist, I guess. It bothers me to see ":=" when "=" will do the job,
> because it's not minimal. 

If you're doing safety critical work then unambiguous should win over
minimalist every time.

-- 

David Gillon

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6624E6.DF734E5C@sneakemail.com>...
> Adrian Hoe wrote:
> > 
> > Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6555ED.9B0B0420@sneakemail.com>...
> > >
> > > 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 "%="?
> > 
> > "=" means equal. "IF A = 0 THEN" reads as "if A equals 0 then" and
> > ":=" means assignment.
> 
> But "x = 4" means that, immediately after the statement is executed, x
> indeed equals 4. I don't see a problem with using "=" for both
> assignment AND equality testing (am I missing something?). In Python,
> the classic C problem of using "=" when you mean "==" is avoided by
> simply not allowing assignment within an if test. Seems like a simple
> solution to me. In Ada, the compiler would tell you if you get it wrong.

"=" and ":=" are used to differentiate a condition and assignment
respectively. Someone in the later post mentioned that "=" has
mathematical interpretation and "==" does not. The same goes to ":=".

Take a look at the code (proposed new Ada):

if A = 0 then
   A = 1;
end if;

rather than (the original Ada):

if A = 0 then
   A := 1;
end if;

Which is clearer? The use of ":=" has the purposeful meaning in
avoiding confusions in apes like us. Certainly, there is no big deal
with a compiler.



> > > 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.
> > 
> > Honestly, if you think Ada already has excellent fundamentals, why
> > border a change?
> 
> Because I'd like to have a language that has both excellent fundamentals
> AND a clear, minimal syntax. I want it all. And I'm a compulsive
> minimalist, I guess. It bothers me to see ":=" when "=" will do the job,
> because it's not minimal. I'm also a fricking perfectionist--just ask my
> wife. :-)


I am a perfectionist myself and you don't have to ask my wife. You can
see the way I work (if you can see now). To achieve perfection, one
has to achieve and maintain balance. Too much preferences on one side
becomes extremist.

Can you have a safe and economic sports car capable of 0-100km/h in 2
seconds and a top speed of 1000km/h? You will have to risk your life
to be in the car if such car exists. (In fact, some prototypes have
already achieved Mach 1.)

If such car exists, it will be a technology breakthrough. A blink of
your eye or a jerk in your hand can bring disasters. The example above
illustrate this scenario. The compiler will just compile whatever you
feed but human is the major contributor of mistakes.

This analogy = your proposed Ada.

Adrian Hoe

> Russ

Re: How to make Ada a dominant language

[Russ]

Adrian Hoe wrote:
> 
> Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6624E6.DF734E5C@sneakemail.com>...
> > Adrian Hoe wrote:
> > >
> > > Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6555ED.9B0B0420@sneakemail.com>...
> > > >
> > > > 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 "%="?
> > >
> > > "=" means equal. "IF A = 0 THEN" reads as "if A equals 0 then" and
> > > ":=" means assignment.
> >
> > But "x = 4" means that, immediately after the statement is executed, x
> > indeed equals 4. I don't see a problem with using "=" for both
> > assignment AND equality testing (am I missing something?). In Python,
> > the classic C problem of using "=" when you mean "==" is avoided by
> > simply not allowing assignment within an if test. Seems like a simple
> > solution to me. In Ada, the compiler would tell you if you get it wrong.
> 
> "=" and ":=" are used to differentiate a condition and assignment
> respectively. Someone in the later post mentioned that "=" has
> mathematical interpretation and "==" does not. The same goes to ":=".
> 
> Take a look at the code (proposed new Ada):
> 
> if A = 0 then
>    A = 1;
> end if;
> 
> rather than (the original Ada):
> 
> if A = 0 then
>    A := 1;
> end if;

I think Python has an extremely simple solution to this so-called
"problem". Python simply disallows assignment inside an "if"
conditional. This whole "problem" is only a symptom of the
short-sightednes of C. (That should score me some points!)

> Which is clearer? The use of ":=" has the purposeful meaning in
> avoiding confusions in apes like us. Certainly, there is no big deal
> with a compiler.

Good. Then let the compiler warn you.

Russ

Re: How to make Ada a dominant language

[MALAISE Pascal]

Russ wrote:

> I think Python has an extremely simple solution to this so-called
> "problem". Python simply disallows assignment inside an "if"
> conditional.
Does Python allow assignement in some other instructions, like a return
statement?
What about "return(A=5)"?
Does the reader (and the compiler) have to check the return type of the
function to know if the value is boolean (A = 5) or integer (5, also
assigned to A)?
This would be very ambiguous.
 
-- 
Pascal MALAISE      Thales ATM - PHIDIAS - MW    Tel: +33 5 62 14 56 26
(prof) mailto:Pascal_MALAISE@stna.dgac.fr        Fax: +33 5 62 14 57 23
(priv) mailto:malaise@magic.fr

Re: How to make Ada a dominant language

[Preben Randhol]

On Tue, 31 Jul 2001 21:25:42 -0700, Russ wrote:
> Adrian Hoe wrote:

>> Which is clearer? The use of ":=" has the purposeful meaning in
>> avoiding confusions in apes like us. Certainly, there is no big deal
>> with a compiler.
> 
> Good. Then let the compiler warn you.

That is not a good idea. 

   1. Programmers (read hackers) tend to ignore the warnings while developing

   2. Bogus or too many warnings will make the programmer stop paying
   attention to them, like a fire alarm that goes off often without
   there being any fire.

   3. I don't see any gain what so ever in removing _one_ character as
   it clearly reduces readability as seen in a previous post. If it is
   so hard to type :=, then make a macro and put it on a shortcut.

Just wait until you have coded a bit. Another feature of Ada that you
might not like in the beginning, but later love, is the strictness of
the language which subsequently will give you a lot more errors at
compile time, and very few at runtime. The compiler will usually also
help you understand your mistake with meaningful error messages. Whereas
when I tried C++ briefly, I managed to compile the program, but they
usually failed to run or a lot of runtime errors popped up. "Now why
is this an advantage" one might think, because one will spend a lot
of time debugging to track down a small error one made somewhere in
the code, which would probably be caugth by the compilor. You could have
fixed it in seconds. When you get more used to Ada you tend to make
fewer and fewer mistakes.


Preben

PS: I prefer that my Ada compiler says that I have an error in line XXX
because I might have written: A = 1; and tell me that it should be: A :=
1; than getting loads and loads of warnings about possible bugs, which
may or may not be real.

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

[AG]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9mfk14.pbf.randhol+abuse@kiuk0156.chembio.ntnu.no...

>    3. I don't see any gain what so ever in removing _one_ character as
>    it clearly reduces readability as seen in a previous post. If it is
>    so hard to type :=, then make a macro and put it on a shortcut.

Or just take some typing courses and never again think of that one extra
key-stroke:)
Seriously, is it anyone's claim that a programmer's productivity is limited
by the typing speed?

Re: How to make Ada a dominant language

[Russ]

AG wrote:
> 
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> news:slrn9mfk14.pbf.randhol+abuse@kiuk0156.chembio.ntnu.no...
> 
> >    3. I don't see any gain what so ever in removing _one_ character as
> >    it clearly reduces readability as seen in a previous post. If it is
> >    so hard to type :=, then make a macro and put it on a shortcut.
> 
> Or just take some typing courses and never again think of that one extra
> key-stroke:)
> Seriously, is it anyone's claim that a programmer's productivity is limited
> by the typing speed?

Another one misses the point. The issue is NOT typing. It's clutter.

Russ

Re: How to make Ada a dominant language

[chris.danx]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:3B682668.4687D3CA@sneakemail.com...
> AG wrote:
> >
> > "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> > news:slrn9mfk14.pbf.randhol+abuse@kiuk0156.chembio.ntnu.no...
> >
> > >    3. I don't see any gain what so ever in removing _one_ character as
> > >    it clearly reduces readability as seen in a previous post. If it is
> > >    so hard to type :=, then make a macro and put it on a shortcut.
> >
> > Or just take some typing courses and never again think of that one extra
> > key-stroke:)
> > Seriously, is it anyone's claim that a programmer's productivity is
limited
> > by the typing speed?
>
> Another one misses the point. The issue is NOT typing. It's clutter.

It's not clutter at all; it's the difference between a value and a variable.

A variable can be changed through the use of := but a value is cannot be
changed, only defined.  This means that a value has no state, while a
variable does.

Overloading = to be equality and assignment would lead to confusion of state
and stateless, which isn't a good idea.

The two statements

f(x) := 2x+1
f(x)  = 2x+1

are entirely different, confusing the two by having one statement for both
leads to imprecision.  They are not the same and never will be!

Try an FPL like Clean, Haskell or OCaml and the difference will become
clear.

Re: How to make Ada a dominant language

[Russ]

Preben Randhol wrote:
> 
> On Tue, 31 Jul 2001 21:25:42 -0700, Russ wrote:
> > Adrian Hoe wrote:
> 
> >> Which is clearer? The use of ":=" has the purposeful meaning in
> >> avoiding confusions in apes like us. Certainly, there is no big deal
> >> with a compiler.
> >
> > Good. Then let the compiler warn you.
> 
> That is not a good idea.
> 
>    1. Programmers (read hackers) tend to ignore the warnings while developing

I used the word "warn" in a loose sense. What I meant was to not let the
fricking program compile. This is really a trivial "problem" that
everyone seems to be determined to trip over.

>    2. Bogus or too many warnings will make the programmer stop paying
>    attention to them, like a fire alarm that goes off often without
>    there being any fire.

OK, then get rid of those useless semicolons that constantly nag you.

>    3. I don't see any gain what so ever in removing _one_ character as
>    it clearly reduces readability as seen in a previous post. If it is
>    so hard to type :=, then make a macro and put it on a shortcut.

You're missing the point again. The typing is not the issue. Clutter is
the issue.

> Just wait until you have coded a bit. Another feature of Ada that you
> might not like in the beginning, but later love, is the strictness of
> the language which subsequently will give you a lot more errors at
> compile time, and very few at runtime. The compiler will usually also
> help you understand your mistake with meaningful error messages. Whereas
> when I tried C++ briefly, I managed to compile the program, but they
> usually failed to run or a lot of runtime errors popped up. "Now why
> is this an advantage" one might think, because one will spend a lot
> of time debugging to track down a small error one made somewhere in
> the code, which would probably be caugth by the compilor. You could have
> fixed it in seconds. When you get more used to Ada you tend to make
> fewer and fewer mistakes.

I love the strictness of the language already. But there is a major
difference between strictness and unnecessary clutter, and too many Ada
programmers don't seem to be able to distinguish between the two.

Russ

Re: How to make Ada a dominant language

[Stefan Nobis]

Russ <18k11tm001@sneakemail.com> writes:

> > Take a look at the code (proposed new Ada):
> > 
> > if A = 0 then
> >    A = 1;
> > end if;
> > 
> > rather than (the original Ada):
> > 
> > if A = 0 then
> >    A := 1;
> > end if;
> 
> I think Python has an extremely simple solution to this so-called
> "problem". Python simply disallows assignment inside an "if"

You missed the point: There is no problem with assignment versus equality but
a problem with the readabilty of the code! In the later case a human reader is
able to distinguish between assignment and equality very ease and at first
glance, in the first case he has to take a second look to see, if "=" is used
as assignment or as equality. That's the problem. And Ada is made for better
readabilty so the later version is the better one.

It has nothing to do with the problems in C(++)!

-- 
Until the next mail...,
Stefan.

Re: How to make Ada a dominant language

[Pascal Obry]

Stefan Nobis <stefan@snobis.de> writes:

> Russ <18k11tm001@sneakemail.com> writes:
> 
> > > Take a look at the code (proposed new Ada):
> > > 
> > > if A = 0 then
> > >    A = 1;
> > > end if;
> > > 
> > > rather than (the original Ada):
> > > 
> > > if A = 0 then
> > >    A := 1;
> > > end if;
> > 
> > I think Python has an extremely simple solution to this so-called
> > "problem". Python simply disallows assignment inside an "if"
> 
> You missed the point: There is no problem with assignment versus equality but
> a problem with the readabilty of the code! In the later case a human reader is
> able to distinguish between assignment and equality very ease and at first
> glance, in the first case he has to take a second look to see, if "=" is used
> as assignment or as equality. That's the problem. And Ada is made for better
> readabilty so the later version is the better one.

I agree and what about:

C : Integer;
A : Boolean;

if A = True then
  A = C = 1;
end if;

Of course, the current implementation is quite clear:

if A = True then
  A := C = 1;
end if;

I really think that this whole thread serve to nothing. Russ, the best way to
have your proposal intregrated at some point is to propose it to the
ARG. Maybe they will understand better than us the added value!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: How to make Ada a dominant language

[AG]

"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B6624E6.DF734E5C@sneakemail.com...
> Adrian Hoe wrote:
> >
> > Russ Paielli <18k11tm001@sneakemail.com> wrote in message
news:<3B6555ED.9B0B0420@sneakemail.com>...
> > >
> > > What's so great about ":="? Why not use "$=" or "%="?
> >
> > "=" means equal. "IF A = 0 THEN" reads as "if A equals 0 then" and
> > ":=" means assignment.
>
> But "x = 4" means that, immediately after the statement is executed, x
> indeed equals 4. I don't see a problem with using "=" for both
> assignment AND equality testing (am I missing something?).

I suspect you may be: you are trying to overload the meaning of an equality
mark. That means (if you really insist on that) that the mark itself pretty
much
looses it's unique meaning, becoming dependent on the context and requiring
an additional context/syntax scan around the place to deremine it's meaning.
That's not a very good thing as far as the readability is concerned - just
think
of possible typos which cannot be resolved without context check and are
sure
to mislead on the first read.
Also, the equality mark traditionally meant exactly that - equality, not
asignment.
Ever heard a professional math person wonder aloud how CAN x be equal to
x + 1 unless it is infinite? [That's your requirement I take it: to use
x=x+1?]

> Because I'd like to have a language that has both excellent fundamentals
> AND a clear, minimal syntax. I want it all. And I'm a compulsive
> minimalist, I guess. It bothers me to see ":=" when "=" will do the job

Whell, it doesn't seem like it would.

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

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

[Keith Thompson]

Here's some more background on the use of ":=" for assignment.

The following is an excerpt from a presentation given by Alan
J. Perlis at the ACM SIGPLAN History of Programming Languages
Conference in 1978.

    So both proposals had these constructions as their basis, and they
    differed only in rather small details, some of which have turned
    out to be more important than others.  For example, the Americans,
    following the FORTRAN appropach, had the variable being assigned
    on the left.  The Europeans had it on the right.  The Americans
    used an equals sign for the assignment, thus hiding the fact 
    that there is a direction to the assignment; the Europeans used 
    a directed arrow pointing to the right.  When ALGOL 58 came out,  
    neither equals nor directed arrow was used, but a colon-equal
    and it pointed to the left.

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

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

[Larry Kilgallen]

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

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

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

[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

[Larry Kilgallen]

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

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

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

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

[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

[Ted Dennison]

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

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

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

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

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

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

[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

A Directory package for Ada (was: How Ada could have prevented)

[Larry Kilgallen]

In article <tn1uu2jl6g54c5@corp.supernews.com>, "David Starner" <dstarner98@aasaa.ofe.org> writes:
> "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?

There is typically an input string (or three) giving the specification
of the desired file.  Wildcard characters "*" and "%" within the string
provide for subsetting the group of files.  Important to this discussion
(and I never thought of this until now) they also allow specification
of a trailing ";" to indicate that only the most recent version should
be taken.  Some FTP servers on VMS include or exclude the trailing ";"
in response to a binary control, and also suppress the version portion
of the output string in response to a separate binary control (to help
programs on other systems that do not know how to handle a version
string properly).

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

I understand that as a goal of a common scheme.  I have run into too
many C programs on VMS imported from other operating systems that took
the simplistic approach and botched the job by leaving those two binary
controls in whatever state happened to naturally occur to the author.

As an example, to read a particular file in the directory would need
just the latest version if you are writing a compiler but would need
all versions if you are writing an archiving program.  To construct
the filespec for the modified copy of the file you are about to write
would require no version in the string, whereas to reliably be able
to reopen the file you just learned about (and not a subsequent version)
would require a version in the string.

Parsing the filenames, incidentally, is not a simple exercise in
string handling.  Besides [].; there are [].. <>.; and <>.. forms
of separators, and if the VMS disk in question happens to be the
newer ODS-5 format, there can be dots and other strange characters
scattered throughout the filename, but not significant for dividing
the filespec.  One really needs to call a system service to get this
right.

On a simpler scale, I recently ran into a "portable" C program that
relied upon inserting a system-specific character to separate the
next level of subdirectory.  On VMS that would be the . characters
in the partial filespec [sub1.sub2.sub3] for an arbitrary example.
But this program was written (for Windows and Unix) under the
presumption that one merely inserted the special character and the
subdirectory name to advance to the next subdirectory level.
That would produce something like [sub1.sub2.sub3].sub4 which is
not exactly the requires [sub1.sub2.sub3.sub4].

You can easily say you don't care about VMS, but if you decide to
not make the package general you will run into problems on some
operating system you don't know about.  OS400 and MVS are examples
of two operating systems I don't know about.

(I leave to another day the discussion of "or three" in my first
sentence above.  It gets complicated.)

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

[Ted Dennison]

In article <3B721BC3.76A2161C@home.com>, Warren W. Gay VE3WWG says...
>
>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,

Mostly true. However, the bounds (actually, just the length from what I've seen)
are only written out if 'Output is used. 'Write just writes out all the
characters in the string one-by-one. In that case it's up to the user to somehow
know how big the string is supposed to be when reading it back.

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

Right.

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

However, you can also create a whole new stream class, if you really want to.

(Regaurding Annex E:)
>Well, XDR _might_ only be true for GNAT's implementation. I wouldn't
>necessarily "expect" it to be so everywhere else.  However, where 

Well, when someone else *has* an implementation, perhaps we will find out. :-)

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

[Warren W. Gay VE3WWG]

Ted Dennison wrote:
> In article <3B721BC3.76A2161C@home.com>, Warren W. Gay VE3WWG says...
> >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,
> 
> Mostly true. However, the bounds (actually, just the length from what I've seen)
> are only written out if 'Output is used. 'Write just writes out all the
> characters in the string one-by-one. In that case it's up to the user to somehow
> know how big the string is supposed to be when reading it back.

Oh, yes-- quite right. I assumed a knowledge of the difference between
'Write and 'Output, and should have pointed that out here.

> >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.
> 
> Right.
> 
> >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.
> 
> However, you can also create a whole new stream class, if you really want to.

I did think about this when I wrote the last post. The problem is that
depending upon what you mean by "whole new stream class", I don't 
think it would help in the Ada context. If you derived a new stream,
the 'Write and 'Output attributes are still called as before. If you
wrote your own stream from scratch, then I'm not certain that 'Write
and 'Output would even be invoked (I've never tried to write a new
stream from scratch :-)  If those attributes are invoked, then you
are back where you started =)

Maybe you can elaborate on what you meant by this, or am I simply
missing something here?

> (Regaurding Annex E:)
> >Well, XDR _might_ only be true for GNAT's implementation. I wouldn't
> >necessarily "expect" it to be so everywhere else.  However, where
> 
> Well, when someone else *has* an implementation, perhaps we will find out. :-)

What about AONIX and others? How do they implement it? 

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

Data portability with streams

[Ted Dennison]

In article <3B732365.81CFD607@home.com>, Warren W. Gay VE3WWG says...
>
>Ted Dennison wrote:
>> >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.
>> 
>> However, you can also create a whole new stream class, if you really want to.
>
>depending upon what you mean by "whole new stream class", I don't 
>think it would help in the Ada context. If you derived a new stream,

I was just being flip. You are quite correct that a stream reimplementation
alone wouldn't do anything for this particular problem. However, implementing
custom stream I/O attributes for everything is not an enviable task, and may
make those types a pain to use for other streams (I think I went into this a bit
in another post about ASN.1).

You can sort of think of the stream I/O attributes as the way of changing data
representation, and the streams themselves as the way of representing a
data-neutral medium. So if you want to represent encrypted data, a buffer, or a
disk file, you'd use a stream. If you want to represent ASN.1 or XDR, you are
talking about custom stream I/O attributes. (If you want a circular buffer that
drops old data only on record boundries, you've got something in between, but
that's a whole topic unto itself...)

I think one possible way to do this without causing a ton of work would be to
create a "translation generic" for each target (ASN.1 or XDR) type. Hmmm. That
might be worth experimenting with one day...

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

Re: Data portability with streams

[Robert Dewar]

Ted Dennison<dennison@telepath.com> wrote in message news:<KqRc7.5104$NJ6.23394@www.newsranger.com>...
> I think one possible way to do this without causing a ton of work 
> would be to create a "translation generic" for each target (ASN.1 or 
> XDR) type. Hmmm. That might be worth experimenting with one day...

In GNAT, this is most easily achieved by providing your own version
of System.Stream_Attributes. We supply two, one corresponding to normal
memory layout, and one corresponding to XDR.

Re: Data portability with streams

[Ted Dennison]

In article <5ee5b646.0108100913.42e2b744@posting.google.com>, Robert Dewar
says...
>
>Ted Dennison<dennison@telepath.com> wrote in message news:<KqRc7.5104$NJ6.23394@www.newsranger.com>...
>> I think one possible way to do this without causing a ton of work 
>> would be to create a "translation generic" for each target (ASN.1 or 
>> XDR) type. Hmmm. That might be worth experimenting with one day...
>
>In GNAT, this is most easily achieved by providing your own version
>of System.Stream_Attributes. We supply two, one corresponding to normal
>memory layout, and one corresponding to XDR.

That's kinda neat! It handles the built-in types, rather than the user-defined
ones. The main reason I thought the generics would be useful would be for
dealing with all the user-defined types. There are only going to be a certian
amount of possible "destination" types in the encoding, but there are an
unlimited number of possible user-defined types. However, those must be built
using base types, so being able to rewrite your base types' attributes might
take care of most of the problem much more easily. 

This still won't take care of ASN.1's array and record encoding types though.
You could just ignore that issue by pretending everything is just sequences of
individual objects, but I take it that the "DER" that I've heard mentioned would
prohibit that.

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

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

[Bart.Vanhauwaert]

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.

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

[tmoran]

>If Intel did offer some version of their 80x86 family in a deep-space,
>...
>One of the beauties of the 1750a was the indivisible nature
>of the instructions, their simplicity and predictability. For hard-realtime
  I wonder how much performance loss there would be if you eliminated
all the fancy pipelining etc etc from a Pentium IV, in order to simplify
timing estimates?  As much as 1/2?  Continue to run at 1GHz, of course.

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

[Florian Weimer]

tmoran@acm.org writes:

>   I wonder how much performance loss there would be if you eliminated
> all the fancy pipelining etc etc from a Pentium IV, in order to simplify
> timing estimates?  As much as 1/2?  Continue to run at 1GHz, of course.

If you eliminate the pipeline from the Pentium IV, I don't think you
can still run it at 1 GHz.

(BTW, a local computer dealer advertised the Pentium IV, referring to
its much longer pipeline length in comparison to the Pentium III. ;-)

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

[Marin David Condic]

Well, it typically isn't done to simplify timing estimates. Its done to be
sure that in the absolute worst case execution of the code, the timing
remains *predictable*. Rocket guys loathe things that aren't predictable
because they have enough unpredictabilities to deal with without throwing
timing uncertainties into the mix.

If you run through a routine in its worst case path and it takes N
milliseconds, you know that you aren't going to generate conditions under
which that is going to vary. Hence, when you pile all of the code together
and it runs worst case scenarios and you still have time left on the CPU
budget, you *know* that you aren't going to generate some sort of wierd
combination or permutation of execution paths that change this behavior.
Throw in cache and pipelining and then you've got to test the wierd
permutations to be sure you don't blow the CPU budget. That can range from
somewhere between extremely difficult to impossible - depending on your
scheduler.

Granted, if you have a CPU wherein you're only using 30% of the timing
budget under all of your tested conditions, you can probably do enough
analysis to figure out that the probability of any sort of cache or pipeline
combinations blowing the CPU budget is extremely low. But the metal benders
that tend to control deep space projects might not understand or accept
this - they like to deal with certainty. That and you seldom find yourself
with the luxury of running a state of the art microprocessor in the
gigahertz range - or if you did, it gets limited by the access speed of
memory or some other device. And even if you had 90% spare CPU budget, you
*know* that there's going to be someone who will find something to do with
it eventually - or tell you that the system is overbuilt and make you use a
cheaper part! :-)

But your point is taken - with many modern processors you could probably
eliminate the cache and pipelining and maybe do some other things to create
a more predictable (yet slower) device and still be coming out ahead. (I bel
ieve this was the idea behind the RH-32) The problem is that there aren't a
lot of silicon foundaries willing to make you a RAD-hard, custom version of
their chip (with all the required testing and certification) when the number
of chips you want to buy is measured in the hundreds.

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/


<tmoran@acm.org> wrote in message
news:sGhi7.17722$sa.8914739@news1.rdc1.sfba.home.com...
> >If Intel did offer some version of their 80x86 family in a deep-space,
> >...
> >One of the beauties of the 1750a was the indivisible nature
> >of the instructions, their simplicity and predictability. For
hard-realtime
>   I wonder how much performance loss there would be if you eliminated
> all the fancy pipelining etc etc from a Pentium IV, in order to simplify
> timing estimates?  As much as 1/2?  Continue to run at 1GHz, of course.

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

[Gary Scott]

Hi,

Marin David Condic wrote:
> 
<snip>
 
> But your point is taken - with many modern processors you could probably
> eliminate the cache and pipelining and maybe do some other things to create
> a more predictable (yet slower) device and still be coming out ahead. (I bel
> ieve this was the idea behind the RH-32) The problem is that there aren't a
> lot of silicon foundaries willing to make you a RAD-hard, custom version of
> their chip (with all the required testing and certification) when the number
> of chips you want to buy is measured in the hundreds.

We very frequently have to buy out the remaining stock of parts to
insure sufficient supply to meet known needs. We recently tried to buy
some parts in the 20 piece range and were required to place a minimum
200 piece order (not in itself a bad thing to have plenty of spares, but
a little excessive in this case).  They wouldn't produce them for a
lesser quantity order.  When you create products with 30 year life
spans, it's a considerable problem.  But we now use whiz bang design
software to develop rapid prototype parts (e.g. ASICs) and PCBs that
provide form-fit replacements with identical functionality using
currently available parts.

> 
> 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/
> 
> <tmoran@acm.org> wrote in message
> news:sGhi7.17722$sa.8914739@news1.rdc1.sfba.home.com...
> > >If Intel did offer some version of their 80x86 family in a deep-space,
> > >...
> > >One of the beauties of the 1750a was the indivisible nature
> > >of the instructions, their simplicity and predictability. For
> hard-realtime
> >   I wonder how much performance loss there would be if you eliminated
> > all the fancy pipelining etc etc from a Pentium IV, in order to simplify
> > timing estimates?  As much as 1/2?  Continue to run at 1GHz, of course.

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

[Marin David Condic]

Been There. Done That. Got The T-Shirt. :-)

The problem is that in many computer applications (in particular, Aerospace
& Defense) you're building systems that might have 20-30 or more years of
life span. (How long have they been flying B-52's?) However, the computer
industry is totally revolutionizing itself every year to 18 months. The
hottest product available today is going to be ancient history by the time
you get the first production model rolling off the assembly floor. What are
you going to do?

Ada's portability is a big help in that so long as there is a current
processor being supported by an Ada compiler, you stand a chance of porting
with minimal fuss. However, the big cost isn't in the coding or even the
design. Its the testing and certification. A whole new Gazorenthorpe on an
airplane or rocket is going to cost you a bundle to re-flight-certify.

The best you can hope for is to be certain that this is going to happen
somewhere in the life of the system and allow for it in the plan.

Now the extra bad news: The poor SOB's who have to work on these projects
become intimate experts in some ancient and arcane computer system and  when
the project finally goes casters-up, they are viewed as relics that are
unemployable. Maybe jobs like that should come with Golden Parachutes in
order to attract and keep good people working on them?

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/


"Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
news:3B8A5CBE.CA62B5CD@lmtas.lmco.com...
>
> We very frequently have to buy out the remaining stock of parts to
> insure sufficient supply to meet known needs. We recently tried to buy
> some parts in the 20 piece range and were required to place a minimum
> 200 piece order (not in itself a bad thing to have plenty of spares, but
> a little excessive in this case).  They wouldn't produce them for a
> lesser quantity order.  When you create products with 30 year life
> spans, it's a considerable problem.  But we now use whiz bang design
> software to develop rapid prototype parts (e.g. ASICs) and PCBs that
> provide form-fit replacements with identical functionality using
> currently available parts.

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

[tmoran]

> The problem is that there aren't a lot of silicon foundaries willing to
> make you a RAD-hard, custom version of their chip (with all the required
> testing and certification) when the number of chips you want to buy is
> measured in the hundreds.
  Is this a suitable job for FPGAs or such?  How about developing not just
an Ada OS, but a CPU to go with it?  :)

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

[Marin David Condic]

Seems like you could define your own instruction set and then write an
emulator for it and hope one day that someone implements your instruction
set in silicon - or maybe the computer manufacturers would adopt your
emulator because it justifies why everyone needs to buy an even faster yet
CPU from them. What should we call it? Hmmmm..... The "Coffee Virtual
Machine"? The "Espresso Virtual Machine"? The "Cappuccino Virtual
Machine"? - Gotta be something like that, eh? :-) As long as we insist that
it is an entirely brandy-new concept that has never been done before and
that we dreampt it up right here today, it ought to catch on like wildfire.
:-)

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/


<tmoran@acm.org> wrote in message
news:4Awi7.19571$sa.10111360@news1.rdc1.sfba.home.com...
>   Is this a suitable job for FPGAs or such?  How about developing not just
> an Ada OS, but a CPU to go with it?  :)

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

[William Dale]

Marin David Condic wrote:
> 
> Seems like you could define your own instruction set and then write an
> emulator for it and hope one day that someone implements your instruction
> set in silicon - or maybe the computer manufacturers would adopt your
> emulator because it justifies why everyone needs to buy an even faster yet
> CPU from them. 

[snip]

This is what Mil-Std-1750A/B tried to do.  Today people think the 1750
is a CPU 
but if you read the standard it is a defined instruction set to promote
re-use of
code.  Of course that never happened ;-)  They made a hardware CPU based
on the 
assembly code instructions.  And nobody reuses 1750 code!  

Bloody awful CPU at that!  Still used on avionics systems like F-22!

William Dale
mailto:william.dale.jr+ada_news@lmco.com

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

[Marin David Condic]

Don't besmirch my beloved 1750! :-)

Sure, it was an instruction set with an eye towards having various hardware
manufacturers build different chips capable of executing it. To some extent
it succeeded.

It wasn't a bad thing. Given the military & aerospace industry's needs the
1750 did a good job of satisfying them. It wasn't all that different from
many contemporary 16 bit micros of its time.

As for code reuse, I don't think anybody had any illusions about "porting"
1750a code all over the place. (other than possibly creating multiple
sources for plug-compatible processors, like, say the 80x86 that Intel
licenses elsewhere?) The basic idea was that if you built tools (compilers,
debuggers, simulators, etc.) that these tools could move from one project to
another and the investment wasn't wasted. This also happened.

The Mil-Std-1750a was an excellent processor for its time and it certainly
has a place in the world today. (Not every app needs a 32bit or bigger
chip!) The problem with it was that by the time anything started to be
settled out about the standard, the computer world had basically moved on to
bigger and better things. Such is life in the world of standards. By the
time you get agreement from a pool of people, some rugged individualist has
pushed the technology beyond your standard.

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/


"William Dale" <william.dale.jr+adanews@lmco.com> wrote in message
news:3B8AD8DE.5C309B0A@lmco.com...
>
> This is what Mil-Std-1750A/B tried to do.  Today people think the 1750
> is a CPU
> but if you read the standard it is a defined instruction set to promote
> re-use of
> code.  Of course that never happened ;-)  They made a hardware CPU based
> on the
> assembly code instructions.  And nobody reuses 1750 code!
>
> Bloody awful CPU at that!  Still used on avionics systems like F-22!
>
> William Dale
> mailto:william.dale.jr+ada_news@lmco.com

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

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

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

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

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

[Ted Dennison]

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

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

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

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

[Ted Dennison]

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

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

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

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

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

[Chris Wolfe]

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

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

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

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

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

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

Chris

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

[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

[Ted Dennison]

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

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

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

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

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

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

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

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

[Martin Ambuhl]

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

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

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

[cppwiz]

[Note: headers have been trimmed]

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

<deleted>

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

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

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

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

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

[Stanley R. Allen]

Ted Dennison wrote:

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

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

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

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

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

[Larry Kilgallen]

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

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

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

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

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

[Ted Dennison]

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

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

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

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

[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

[Ted Dennison]

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

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

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

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

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

Again, great for Microsoft, crappy for security.

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

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

[Warren W. Gay VE3WWG]

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

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

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

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

> Again, great for Microsoft, crappy for security.

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

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

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

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

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

[David Starner]

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

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

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

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

[Warren W. Gay VE3WWG]

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

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

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

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

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

[Warren W. Gay VE3WWG]

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

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

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

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

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

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

[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

Evil browser-specific web sites (was: How Ada could have prevented the Red Code distributed denial of service attack.

[Ted Dennison]

In article <9hja7.1803$tQ5.728008@news2-win.server.ntlworld.com>, chris.danx
says...
>"Florian Weimer" <fw@deneb.enyo.de> wrote in message
>news:87r8uvuu48.fsf@deneb.enyo.de...
>> 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!

:-)

Now you know how we Mozilla users feel about all those stupid IE-only sites. :-)

I *have* to use IE for newsreading, because my free newsreader service
(newsranger) refuses to fix some IE-extensions they put in the posting code
(causing postings made with other browsers to wrap in a really stupid manner). I
even went so far as to look at the HTML source and debug the issue myself, but
they don't care. And of course this is exactly what Microsoft was hoping would
happen when they introduced their browser extensions.

Not that I support what this site did to you (acutally, *us*, as I clicked it
from my news browser window and got the same message). Two wrongs don't make
right, and this is *just* as bad and obnoxious as all those IE-specific sites
out there. However, I hope you can now at least see the larger issue for what it
is.

As a counter-measure, I'd feel better about just refusing to link to any
browser-specific sites. If they don't want to be part of the
platform-independent internet as it was intended to be, then we should *let*
them be their own separate IE-internet. :-)

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

Re: Evil browser-specific web sites (was: How Ada could have prevented the Red Code distributed denial of service attack.

[Larry Kilgallen]

In article <T7ya7.16220$ar1.58734@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:

> As a counter-measure, I'd feel better about just refusing to link to any
> browser-specific sites. If they don't want to be part of the
> platform-independent internet as it was intended to be, then we should *let*
> them be their own separate IE-internet. :-)

	http://www.tbtf.com/exclusionary.html
	http://www.anybrowser.org/campaign/

Re: Evil browser-specific web sites (was: How Ada could have prevented the Red Code distributed denial of service attack.

[chris.danx]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:T7ya7.16220$ar1.58734@www.newsranger.com...
> In article <9hja7.1803$tQ5.728008@news2-win.server.ntlworld.com>,
chris.danx
> says...
> >"Florian Weimer" <fw@deneb.enyo.de> wrote in message
> >news:87r8uvuu48.fsf@deneb.enyo.de...
> >> 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!
>
> :-)
>
> Now you know how we Mozilla users feel about all those stupid IE-only
sites. :-)

Yes!  It's not nice at all is it?

I just downloaded the most recent build of Mozilla and it's very nice.  In
fact, I'm gonna dump IE from now on since Mozilla will (or does) have
mathML support and I've heard now't about IE getting it.  The only thing I
didn't like about Mozilla for Windows was in the news reader.  Threaded and
other ordering options are mutually exclusive for now, but in OE you can
have threaded *and* order on name, sender and date(the usual?), which is
easier to use IMO.  The other thing I almost forgot about was that I
couldn't get it to work with my hotmail account because it's different from
other accounts :-(  Still it's not at 1.00 stage yet, they may introduce
these sometime and it's very good regardless.


> I *have* to use IE for newsreading, because my free newsreader service
> (newsranger) refuses to fix some IE-extensions they put in the posting
code
> (causing postings made with other browsers to wrap in a really stupid
manner). I
> even went so far as to look at the HTML source and debug the issue
myself, but
> they don't care. And of course this is exactly what Microsoft was hoping
would
> happen when they introduced their browser extensions.

That's not good at all Ted.  I feel sorry for you :-(


> Not that I support what this site did to you (acutally, *us*, as I
clicked it
> from my news browser window and got the same message). Two wrongs don't
make
> right, and this is *just* as bad and obnoxious as all those IE-specific
sites
> out there. However, I hope you can now at least see the larger issue for
what it
> is.

The internet is for everyone and to ensure this is so, follow the standards
and/or do not treat other ppl with contempt simply because they use a
different tool?  I probably haven't explained this very well, but I do know
what you mean.

> As a counter-measure, I'd feel better about just refusing to link to any
> browser-specific sites. If they don't want to be part of the
> platform-independent internet as it was intended to be, then we should
*let*
> them be their own separate IE-internet. :-)

Agreed.  Although I must say that my site was until tonight not very
friendly to browsers, like Amaya(?), that do not support frames.  I decided
that this is a bit hypocritical and have modified it a bit to work with
frame-less browsers (it's not quite finished; html takes forever to edit
:-( ).


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

[Warren W. Gay VE3WWG]

David Lee Lambert wrote:
> 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).

This _might_ be true if your String class was used everywhere -- but its
not. As long as you continue to have to use pointers to strings, arrays
of NUL terminated strings, calls to strncpy(), strcpy(), etc., you are
_still_ exposed to all the human foibals of array bounds errors and
abuse.

A vector<T> class is all fine and dandy too. But what will you use when
you call pipe(2)?  Why you'll use a naked int fd[2] array just like you
always did in C. So what's the problem you say?

void foo() {
   int fd[2];				// 2 file descriptors from pipe(2)

   if ( pipe(&fd[0]) != -1 ) {           // Create pipe with 2 fd's
      Call_Some_Other_Function(fd[2]);   // whoops -- no compiler help here

The compiler is no help here, and the runtime won't be either (you will
catch it eventually, when you try to do I/O on the value passed, but
you may be buried 15 function calls deep by then! Welcome to the 
debugger. ;-)

You still have array bounds issues (for the non C/C++ types, the
code tries to access fd[2] which is out of bounds).  Unless you STL
the entire POSIX suite, you _still_ have array bounds issues. Again,
if you use msgrcv(2)/msgsnd(2) you'll be using the naked char[] array
for the message, within the structure.  Your STL is no help to you
here.

This seems to be the type of issue that many C++ people forget in 
these discussions. Sure the STL (or any other class) can implement
checks in them. But it does _not_ change the dangers of the language
and all of the other infrastructure that is still with you.

Now in Ada, you may need to call pipe(2) or msgrcv(2)/msgsnd(2) also.
But in Ada, you have full checks in place (unless purposely disabled).
So the access to fd(2) (assuming array bounds 0..1) would have been
caught at compile time (because this can be determined statically).
If it had been more dynamic (accessed by variable subscript), it 
would immediately raise an exception at run time.

And you can define variant structures (records) to meet the need of
the msgsnd(2) call, for example. All access to the arrays are fully
checked, and bugs will be caught early in the testing, and caught
at the source. Not 15 function levels deep.

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

Much of it is laziness. I have seen people use scanf() for things
they could have done safely themselves or by other means. I continue
to see atoi()/atol() or atof() used instead of strtol() for example
(atoi() blithly returns zero if the conversion from a string to 
integer fails). 

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

But again, there are examples like the pipe(2) where this does not
solve the problem. Maybe growth is not the correct solution. Maybe
the access is a "bug" instead. ;-)

> 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

You're expressing your decision based on your experience, which is fine. 
However, given that, what this thread boils down to now however (if Ada 
is the better language) is that someone else can write a more secure 
web server than you, because they are not handicapped by this lack 
of experience, using this better tool.

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

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

[CBFalconer]

David Lee Lambert wrote:
> 
... snip ...
> 
> 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()...

Oh, how about:

#define BUF1SZ 10
...
#define BUF2SZ 20
...
char buff1[BUF1SZ]
...
     fgets(buf1, BUF2SZ, stdin);

and I have no idea where the error will hit.  The equivalent in
any range checking language will hit at the read, if not at the
compile.  Before you say the programmer shouldn't have done that,
consider the thousands of lines that may be represented by the ...
and that the statements may even be in different files.

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

[Marin David Condic]

Or someone redefined you #define somewhere between when you declared your
array and when you called the function. Never happens? What about when you
start bringing in header files with the #include? How many times do
programmers use names like "MAXSIZE" or "BUFFSIZE" or similar? How about
really big files with dozens or hundreds of functions in them? Its *way*
easy to get that kind of error into a program.

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:3B6CD64F.E96911F8@yahoo.com...
> David Lee Lambert wrote:
> >
> ... snip ...
> >
> > 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()...
>
> Oh, how about:
>
> #define BUF1SZ 10
> ...
> #define BUF2SZ 20
> ...
> char buff1[BUF1SZ]
> ...
>      fgets(buf1, BUF2SZ, stdin);
>
> and I have no idea where the error will hit.  The equivalent in
> any range checking language will hit at the read, if not at the
> compile.  Before you say the programmer shouldn't have done that,
> consider the thousands of lines that may be represented by the ...
> and that the statements may even be in different files.
>

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

[Mike Silva]

Had that exact thing happen to me just last week, where some code for
a new piece of hardware decided to fill in a structure intended for an
old piece of hardware, and ended up trying to stuff 6 quarts into a 4
quart jug.  Spent half a day finding the problem.  Chalk up one more
for my ongoing "wouldn't have happened in Ada" list!

Mike

"Marin David Condic" <dont.bother.mcondic.auntie.spam@acm.org> wrote in message news:<9kmd5a$euq$1@nh.pace.co.uk>...
> Or someone redefined you #define somewhere between when you declared your
> array and when you called the function. Never happens? What about when you
> start bringing in header files with the #include? How many times do
> programmers use names like "MAXSIZE" or "BUFFSIZE" or similar? How about
> really big files with dozens or hundreds of functions in them? Its *way*
> easy to get that kind of error into a program.
> 
> 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:3B6CD64F.E96911F8@yahoo.com...
> > David Lee Lambert wrote:
> > >
>  ... snip ...
> > >
> > > 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()...
> >
> > Oh, how about:
> >
> > #define BUF1SZ 10
> > ...
> > #define BUF2SZ 20
> > ...
> > char buff1[BUF1SZ]
> > ...
> >      fgets(buf1, BUF2SZ, stdin);
> >
> > and I have no idea where the error will hit.  The equivalent in
> > any range checking language will hit at the read, if not at the
> > compile.  Before you say the programmer shouldn't have done that,
> > consider the thousands of lines that may be represented by the ...
> > and that the statements may even be in different files.
> >

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 a modern programming language could have prevented the Red Code distributed denial of service attack.

[raj]

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

The problem is made worse when one considers that much of the code in
programs we use everyday ( I think of sendmail , perl and apache ) was
written by enthusiastic amateurs.

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

Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Marin David Condic]

Presuming for a minute that the initial target will be some popular platform
like a PC and you have some ability to come up with an Ada compiler capable
of targeting a bare-board 80x86 processor, then I'd strongly suggest that as
an initial route. Don't start reinventing the wheel - go build something
that isn't already built - namely an OS - which is, after all, the stated
goal.

If some progress were shown on that front, you might even find more
volunteers to work on it because they'd have a new "toy" to play with. Who
needs yet another Ada compiler to play with? Long term, I can understand the
reasons for wanting an Ada compiler to go with the AdaOS - but that could be
a secondary, parallel effort. Get some part of an OS that might be usable in
some realm and then you've got something unique to show for your efforts.

Clearly, if there were some R&D money available for this, it might actually
speed things along. Don't know if maybe there is an SBIR proposal or some
other sort of research grant money that might be had - but if it paid a few
bucks to generate some results, chances are you'd see more results. It might
even help speed development if the ultimate license for the thing offered
some chance of financial reward to the developers - but I've hawked that
issue before. (Money now or money later might have a way of speeding things
up a bit.)

I won't be critical of volunteers who may not find enough incentive there to
really push the issue and get something done in what I'd consider a timely
manner. However, I'd suggest that we don't hold this up as an example of how
Ada can be used to develop an OS - especially in posts to other newsgroups.
Instead, refer to RTEMS and other real-time efforts that have been done in
Ada. If somewhere along the line, the AdaOS website posts some code, then it
might be fair to refer others to that site as an example.

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/


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B7C3293.76F49097@home.com...
>
> 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.

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Ted Dennison]

In article <9lhefg$lgd$1@nh.pace.co.uk>, Marin David Condic says...
>If some progress were shown on that front, you might even find more
>volunteers to work on it because they'd have a new "toy" to play with. Who

That pretty much nails the problem on the head, as far as I'm concerned. If you
read much about the theory of "OpenSource" projects, you'd see that successful
ones mostly started off with a single developer releasing something small and
nominally useful, which then picked up a few developers willing to improve it,
so that a "snowball" effect occurs. You don't start with a huge group of
volunteers and a website with dicsussion boards and all the trimmings, *then*
make a useful product.

>I won't be critical of volunteers who may not find enough incentive there to
>really push the issue and get something done in what I'd consider a timely

Again, I agree here totally. I actualy feel really bad expressing my feelings on
this subject, because I do really like and respect the people I know who have
signed up on that project. I still hold out hope that Nick will just ignore the
website and everything else for a few months and churn out something basic that
folks can get started hacking on. But my pessimistic nature keeps telling me
otherwise...

>manner. However, I'd suggest that we don't hold this up as an example of how
>Ada can be used to develop an OS - especially in posts to other newsgroups.
>Instead, refer to RTEMS and other real-time efforts that have been done in
>Ada. If somewhere along the line, the AdaOS website posts some code, then it
>might be fair to refer others to that site as an example.

Right now AdaOS is an OS discussion group, and nothing much more. In the
meantime, there are probably hundreds, if not thousands, of small Ada OS's
running in stuff like rockets, smartbombs, and airplanes.

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

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Jeffrey Carter]

The AdaOS people have decided they need to write a compiler before they
can write an OS. Without discussing whether they are correct, I see a
parallel with the GNU project. GNU (GNU's Not Unix) was a project to
write an OS. They decided they needed to write a compiler first. While
the result was a very useful free compiler, it is instructive to note
that GNU never created an OS.

-- 
Jeffrey Carter

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Marin David Condic]

Well, I can see where GNU fell on its face with respect to their original
goal & maybe this is a big risk for AdaOS.

Putting my Project Manager hat on for a moment...

Presuming that the insistence on building their own compiler is not
negotiable, I'd offer this advice: Put a small handful of guys to work on
getting a small subset of Ada implemented - just enough to be useful for
writing some bootstrap and kernel code. Then get everyone else working on
the bootstrap & kernel code using whatever subset was targeted and use
whatever compilers are available. IOW, get the OS part of AdaOS off of
bottom-dead-center and get some kind of usable, working product out there.
No reason the compiler has to be there first - or with all of Ada fully
supported. Get *SOMETHING* out there that makes it look like a real project
and maybe this will start the snowball building.

Otherwise, people will lose interest in the project and the general public
will latch onto other things that are real and technology will march onward
possibly making the very concept of AdaOS a historic oddity as it becomes
OBE. Get something out there or the project is going to die.

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/


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3B7D47F1.25D6FC78@boeing.com...
> The AdaOS people have decided they need to write a compiler before they
> can write an OS. Without discussing whether they are correct, I see a
> parallel with the GNU project. GNU (GNU's Not Unix) was a project to
> write an OS. They decided they needed to write a compiler first. While
> the result was a very useful free compiler, it is instructive to note
> that GNU never created an OS.
>

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Ted Dennison]

In article <3B7D47F1.25D6FC78@boeing.com>, Jeffrey Carter says...
>
>The AdaOS people have decided they need to write a compiler before they
>can write an OS. Without discussing whether they are correct, I see a
>parallel with the GNU project. GNU (GNU's Not Unix) was a project to
>write an OS. They decided they needed to write a compiler first. While
>the result was a very useful free compiler, it is instructive to note
>that GNU never created an OS.

Well, there is HURD, but I don't think its reached 1.0 yet.

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

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:
> The AdaOS people have decided they need to write a compiler before they
> can write an OS. Without discussing whether they are correct, I see a
> parallel with the GNU project. GNU (GNU's Not Unix) was a project to
> write an OS. They decided they needed to write a compiler first. While
> the result was a very useful free compiler, it is instructive to note
> that GNU never created an OS.

I think this was unavoidable in _their_ case. Writing an O/S of any
kind at the time they started would have required that everyone involved
purchase a compiler, or make-do with some simple shareware one. So I
don't find any fault with their approach, because they simply had no
other choice (also thanks to this effort in part, we have GNAT).

In the AdaOS case however, I don't feel that it was essential to create
a new compiler. I think Nick even expressed his reason as being one of
"wanting to do that", which is fine (people should enjoy what they do
in their spare time). I'd even welcome additional free Ada 
compilers to choose from but, I feel that this is a rather ambitious
undertaking, when you're planning on delivering an OS as well.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Robert Dewar]

Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B7D47F1.25D6FC78@boeing.com>...
> GNU (GNU's Not Unix) was a project to
> write an OS. They decided they needed to write a compiler first.
> While the result was a very useful free compiler, it is instructive 
> to note that GNU never created an OS.

What Jeffrey meant to say (I guess) was that "GNU never created an
OS that he had heard about" [or should I say "had HURD about"?] But
I am not quite sure why the fact that Jeffrey is not aware of this
OS is instructive :-) :-)

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[David Starner]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0108171856.18631c4c@posting.google.com...
> Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message
news:<3B7D47F1.25D6FC78@boeing.com>...
> > GNU (GNU's Not Unix) was a project to
> > write an OS. They decided they needed to write a compiler first.
> > While the result was a very useful free compiler, it is instructive
> > to note that GNU never created an OS.
>
> What Jeffrey meant to say (I guess) was that "GNU never created an
> OS that he had heard about" [or should I say "had HURD about"?] But
> I am not quite sure why the fact that Jeffrey is not aware of this
> OS is instructive :-) :-)

True; making an OS is about as easy as making a compiler. Making a useful
OS, however, is much harder. Considering the problems with the Hurd (massive
security and stability problems), and the fact that there's no installation
program - merely a lengthy installation procedure - I would hardly classify
the Hurd as useful. It might at best be classified as interesting.

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

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Jeffrey Carter]

Robert Dewar wrote:
> 
> Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B7D47F1.25D6FC78@boeing.com>...
> > GNU (GNU's Not Unix) was a project to
> > write an OS. They decided they needed to write a compiler first.
> > While the result was a very useful free compiler, it is instructive
> > to note that GNU never created an OS.
> 
> What Jeffrey meant to say (I guess) was that "GNU never created an
> OS that he had heard about" [or should I say "had HURD about"?] But
> I am not quite sure why the fact that Jeffrey is not aware of this
> OS is instructive :-) :-)

I have heard of Hurd, but it does not seem to be the OS that GNU set out
to create. Since the OS they set out to create was to be called GNU, so
I don't see how Hurd could be that OS. However, I could have been more
precise, and said "GNU has yet to create the OS that it set out to
create.".

Even if we count Hurd as GNU, the time it took the project to create
Hurd may be instructive as to how long we should expect the AdaOS
project to take to create AdaOS if it creates a compiler first.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Florian Weimer]

Jeffrey Carter <jrcarter@acm.org> writes:

> I have heard of Hurd, but it does not seem to be the OS that GNU set out
> to create.

The Hurd is the kernel of the GNU operating system, at least in
theory.

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Ted Dennison]

In article <3B7F624B.7294D24F@acm.org>, Jeffrey Carter says...
>
>I have heard of Hurd, but it does not seem to be the OS that GNU set out
>to create. Since the OS they set out to create was to be called GNU, so

However, it *is* that OS. The name of the *kernel* has changed several times (I
think originally it was going to be "Alix", after an old girlfriend of RMS's),
but the overall OS was always going to be called GNU. That is why they get so
snitty about referring to Linux as "GNU/Linux". In their minds the OS is GNU,
and Linux (or Hurd) is just the kernel.


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

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Marin David Condic]

Well, I suppose they can get as snitty as they like - as is often said in
business "Money talks - Bulls**t Walks." In the end, nobody will care what
the name of it is. The guy that wins is the one with a working OS that can
actually be acquired in some reasonable manner and does something useful.
How many different coloquialisms are there for exactly this situation? "If
you can't run with the big dogs, stay up on the porch". "That dog don't
hunt!" There's "Players" and "Player Haters". The situation must be pretty
common since we have so many ways of describing it. :-)

I was once on a  very large project that was a long time in development with
no visible results to the end-user community. We had the "Official Project X
Joke": A lady tells her analyst that she's been married three times and that
she's still a virgin. The analyst asks her to explain. "My first husband was
impotent, so he couldn't. My second husband was gay, so he wouldn't. My
third husband worked on 'Project X' so he'd just lie there and tell me how
great it was going to be one day."

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/

>
> However, it *is* that OS. The name of the *kernel* has changed several
times (I
> think originally it was going to be "Alix", after an old girlfriend of
RMS's),
> but the overall OS was always going to be called GNU. That is why they get
so
> snitty about referring to Linux as "GNU/Linux". In their minds the OS is
GNU,
> and Linux (or Hurd) is just the kernel.
>
>

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Didier Utheza]

The same problem arrived in the case of freeos (the free OS-2 project).
Actually the soul of the project (the initiator) gave up and this created
a vacuum. People talked a lot but did not have incentive to write some
code. In the case of Hurd, I will say that everybody is right. Hurd
appeared once Linux showed that it was possible to accomplish such a
project. It looks that the GNU fundation took the project out of the
drawer then. It is still an incomplete system. Now, I beleive (I may be
wrong) that the *BSDs were here before Linux. But for some reasons they di
not make it in front of the scene (possible reasons: too many divergences
in the core development team: OpenBSD, NetBSD, FreeBSd,... that posed
problem for the development of the critical parts, and they missed the
internet horse. I do not say that the *BSDs are not operational. They are
pretty good systems, actually better than Linux in many points (M$ uses a
*BSD system as a server for hotmail after w$nt blew the service up several
times. They still have the audacity to host a webpage that critisize Unix.
An old fellow sure, but it works). But the big wave of internet
cooperation around Linux eventually profited *BSDs, they did not initiate
it.

Now, in the case of AdaOS. The project has, as you said, two major
difficulties. The first one is to develop a C-independent compiler. This
implies to actually develop several kernels to address the various
processor (intel, alpha,...). The development of an Ada compiler is not
given to everybody. Maybe a cooperation between the AdaOS team and the
GNAT group could ease things a little bit. Everyone will gain from it, and
the time spend on it would be less.

The other difficulty is of course to start developping the OS itself. As
it was said in the thread, if you have to wait for the compiler before
developping the OS, it will become a fuzzy dream (it may become it
already). Now since we have GNAT, it is still possible to start something
and the members of the team that direct the project will have to do  at
some point the transition. The GNAT group may be interested (a scary
thing is that c(++) real time system are appearing now - they reinvent 
the wheel!), they may not have the manpower for such a project but have
the experience. Also, many dedicated and embeded AdaOSes exist and the
experience is there. A question: what is the compiler used to develop
these OSes?
The people that say that the project needs to show some code directed to
the OS are rigth. The problem is who is going to do it. Who has the time
and the knowledge to embark in this project?
So, here comes the main question: what happened to Nick Robert. A
leader or leaders (people to keep the project on the move) is needed. Nick
is the one that created the project andnobody seems to know what happens to him (the administrator of the AdaOS
site: Marcelo de Freitas doen't know himself.

At last, there are plenty of people (like me) that play with Ada and do
not have a clue in system/OS programming but would like to help. With a
little bit of directive a lot can be done on the doc, code
duplication,...side.
*BSDs and Linux were able to take off because a limited number of people
with the deep knowledge of OS internals gave to the following layer
something to build upon. It looks that any free open project to develop
through the web would have to follow this path.
There are very good Ada name in the AdaOS project. The knowledge is here,
something just has to be done with the coordination.
That is the most difficult step in my opinion.

			Didier Utheza.

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Marin David Condic]

"Didier Utheza" <ddutheza@bu.edu> wrote in message
news:Pine.A41.4.10.10108201848570.29818-100000@acs5.bu.edu...
>
> Now, in the case of AdaOS. The project has, as you said, two major
> difficulties. The first one is to develop a C-independent compiler. This
> implies to actually develop several kernels to address the various
> processor (intel, alpha,...). The development of an Ada compiler is not
> given to everybody. Maybe a cooperation between the AdaOS team and the
> GNAT group could ease things a little bit. Everyone will gain from it, and
> the time spend on it would be less.
>
Don't know what you mean by a "C-independent compiler". An Ada compiler not
written in C? I don't think it makes much difference.

If it were my project, the first thing to do would be to put the project on
some sort of basis by which the developers stand to make some money off of
it. That would create some incentive to actually get something done.

From there, you just pick a compiler as an interim development tool. (Gnat
would probably do just fine for a time.) I can see why it would be desirable
for the project to have its own compiler eventually, but there are lots of
good compilers that could get you started with what the *real* mission is:
developing an OS. Target the PC architecture initially, but leave the door
open for everything else and work the compiler issue as a sideline effort.

> The other difficulty is of course to start developping the OS itself. As
> it was said in the thread, if you have to wait for the compiler before
> developping the OS, it will become a fuzzy dream (it may become it
> already). Now since we have GNAT, it is still possible to start something
> and the members of the team that direct the project will have to do  at
> some point the transition. The GNAT group may be interested (a scary

That's the point: If you're going to build an OS then build an OS! Stay on
target and don't get distracted by the things that are sideline issues. Get
some minimal, working kernel going and people may get more interested in
contributing as they have something to play with and enhance.


> thing is that c(++) real time system are appearing now - they reinvent
> the wheel!), they may not have the manpower for such a project but have
> the experience. Also, many dedicated and embeded AdaOSes exist and the
> experience is there. A question: what is the compiler used to develop
> these OSes?

Lots of them. It depends on the machine architecture you are looking at. In
the embedded world, you look at your hardware, then start shopping around
for a compiler that targets the hardware & generates the best code for your
problem domain. I believe RTEMS is compilable by Gnat, but should be
compilable (probably mostly - some tweaking is usually necessary) by other
compilers if you have a target that Gnat doesn't support.


> The people that say that the project needs to show some code directed to
> the OS are rigth. The problem is who is going to do it. Who has the time
> and the knowledge to embark in this project?
> So, here comes the main question: what happened to Nick Robert. A
> leader or leaders (people to keep the project on the move) is needed. Nick
> is the one that created the project andnobody seems to know what happens
to him (the administrator of the AdaOS
> site: Marcelo de Freitas doen't know himself.
>
Any project needs some strong leadership to point the direction, inspire the
troops and keep things on-track. An OS is pretty ambitious and I doubt that
it can be done by committee. If a project like this is to succeed, it needs
one (or a very small handful of) dedicated guy(s) with a vision of what it
is supposed to be working on it long enough to get the core off the ground.
Once the direction is set and some initial progress is made, others will see
the direction and work with it.


> At last, there are plenty of people (like me) that play with Ada and do
> not have a clue in system/OS programming but would like to help. With a
> little bit of directive a lot can be done on the doc, code
> duplication,...side.

No doubt anyone could be useful to a project like this, but as you observe,
most people need a little help in being pointed in the right direction. I
have nothing to do with the AdaOS project, so I couldn't advise you about
the goings-on in that group. However, if they did start rolling along and
you thought you'd like to be involved, I'd suggest asking what are the
things that need to be done and find some piece of it that you have *some*
understanding of and work on that. It can be a valuable learning experience,
if nothing else.


> *BSDs and Linux were able to take off because a limited number of people
> with the deep knowledge of OS internals gave to the following layer
> something to build upon. It looks that any free open project to develop
> through the web would have to follow this path.
> There are very good Ada name in the AdaOS project. The knowledge is here,
> something just has to be done with the coordination.
> That is the most difficult step in my opinion.
>
I'd like to see them succeed as well. Certainly, there is tallent and
knowledge on the project, but I believe that unless someone goes off and
develops some small starting piece of it and says "Here it is - lets build
on this" nothing much is likely to come of 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/

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> "Didier Utheza" <ddutheza@bu.edu> wrote in message
> news:Pine.A41.4.10.10108201848570.29818-100000@acs5.bu.edu...
> >
> > Now, in the case of AdaOS. The project has, as you said, two major
> > difficulties. The first one is to develop a C-independent compiler. This
> > implies to actually develop several kernels to address the various
> > processor (intel, alpha,...). The development of an Ada compiler is not
> > given to everybody. Maybe a cooperation between the AdaOS team and the
> > GNAT group could ease things a little bit. Everyone will gain from it, and
> > the time spend on it would be less.
> >
> Don't know what you mean by a "C-independent compiler". An Ada compiler not
> written in C? I don't think it makes much difference.

At this stage of the game, it matters not whether there is C-code in the
compiler or not. As Marin has already pointed out, the focus should be
the OS.  Work on the "purist level motives" later when you have something.

> If it were my project, the first thing to do would be to put the project on
> some sort of basis by which the developers stand to make some money off of
> it. That would create some incentive to actually get something done.

Money would help, but unless some white knight shows up with a keen interest
in the project, I think you have to look elsewhere for motivation. I believe
that many Ada people would be willing to contribute to any AdaOS project that
is showing significant progress. You need achievable milestones, otherwise
the project just languishes.

> From there, you just pick a compiler as an interim development tool. (Gnat
> would probably do just fine for a time.) I can see why it would be desirable
> for the project to have its own compiler eventually, but there are lots of
> good compilers that could get you started with what the *real* mission is:
> developing an OS. Target the PC architecture initially, but leave the door
> open for everything else and work the compiler issue as a sideline effort.

Precisely - target the PC platform, and use what you have. Learn as you go,
as there will be design lessons learned along the way (note the lessons that
Linux has learned, and in some cases re-learned ;-)

> > The other difficulty is of course to start developping the OS itself. As
> > it was said in the thread, if you have to wait for the compiler before
> > developping the OS, it will become a fuzzy dream (it may become it
> > already). Now since we have GNAT, it is still possible to start something
> > and the members of the team that direct the project will have to do  at
> > some point the transition. The GNAT group may be interested (a scary
> 
> That's the point: If you're going to build an OS then build an OS! Stay on
> target and don't get distracted by the things that are sideline issues. Get
> some minimal, working kernel going and people may get more interested in
> contributing as they have something to play with and enhance.

Someone could use GNAT under DOS (even FREEDOS?), which is quick to boot, 
although it is a severe/humble development environment.

Compile your O/S code, and run it, and have it "take over"
the real-mode DOS session, and launch into the test of the O/S. When/if
it crashes, just quickly reboot your DOS session and work on your next
incantation.

You then have the compiler you need, and you don't even have to fuss with
booting issues at this point. The issue at hand, as pointed out above, is
to get _something_ working.

> Any project needs some strong leadership to point the direction, inspire the
> troops and keep things on-track. An OS is pretty ambitious and I doubt that
> it can be done by committee. If a project like this is to succeed, it needs
> one (or a very small handful of) dedicated guy(s) with a vision of what it
> is supposed to be working on it long enough to get the core off the ground.
> Once the direction is set and some initial progress is made, others will see
> the direction and work with it.

I think the "leadership" issue will take care of itself, if someone would
just get started on it. But again, as a hobby, I cannot be critical of
someone who _wants_ to do a compiler. However, if the goal of this hobby
is the OS, then I think that the compiler is just an unnecessary diversion.
This could be done -after- the OS is getting somewhere. After all, the
compiler may need to be different anyway, if the OS is revolutionary
(ie. non POSIX in nature).

> > *BSDs and Linux were able to take off because a limited number of people
> > with the deep knowledge of OS internals gave to the following layer

Just to correct an earlier post : *BSD is the real _UNIX_ from years ago.
It just took a while to have ports of it made available to the PC platform,
but it is the real UNIX; while Linux is the UNIX-like O/S. The first
socket implementation for TCP/IP was on BSD UNIX, for example.

While I personally find the UNIX environment quite comforable etc., I
still favour someone coming up with an Ada O/S that was _secure_. UNIX was
never intended to be secure at the start (although several attempts have
been made since to improve this). Perhaps there is some room for some
new concepts as well =)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Marin David Condic]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B82789B.8D195045@home.com...
>
> Money would help, but unless some white knight shows up with a keen
interest
> in the project, I think you have to look elsewhere for motivation. I
believe
> that many Ada people would be willing to contribute to any AdaOS project
that
> is showing significant progress. You need achievable milestones, otherwise
> the project just languishes.
>
I doubt there is going to be a White Knight who is going to say "I have this
spare $100m lying around - would you guys build me an OS?" However, if there
was some carrot held out in the way of a future reward, maybe some people
would see it as an opportunity to make a few $$$ on the side and devote more
time to it. Putting the OS out under the GPL (or some version thereof) might
not hold out much hope of money. If it was being developed under some more
"restrictive" license such that the developers might be able to make some
$$$ from eventual sales, it might get viewed as a business venture with the
developers investing in sweat equity. Or if it *must* be GPL (because of
some religious zeal?) then doing the work under some corporate structure
wherein contributors are given shares - that is holding out some hope of
future financial rewards. (Think of the ACT model of selling support. First
you have to have a product to support!)


>
> You then have the compiler you need, and you don't even have to fuss with
> booting issues at this point. The issue at hand, as pointed out above, is
> to get _something_ working.
>
Even if it doesn't have a boot loader and is just run as an "App" at some
level, you then have at least something that is working. Even under Win2k -
it could be a kind of "Simulator" program for a while until enough of it got
built to make it worth doing a boot loader and having it take over the
machine.

As you and I both observe - get *SOMETHING* running and the project will
likely start having some legs. Focus on what you *can* do in some reasonable
span of time.


>
> I think the "leadership" issue will take care of itself, if someone would
> just get started on it. But again, as a hobby, I cannot be critical of
> someone who _wants_ to do a compiler. However, if the goal of this hobby
> is the OS, then I think that the compiler is just an unnecessary
diversion.
> This could be done -after- the OS is getting somewhere. After all, the
> compiler may need to be different anyway, if the OS is revolutionary
> (ie. non POSIX in nature).
>
Well the "leadership" almost by definition is going to come from whoever it
is that grabs the bull by the horns and gets something built. That's what
will set the direction of the project and that individual is who everyone
else will look to for further direction.

As for the compiler - I couldn't agree more. A real new OS may provide all
sorts of features that could change the direction of the compiler itself.
Get a bare-board compiler and start building the kernel. When that's done
and you actually have some OS services to call, that's when you'll start
seeing where to take the compiler - assuming you still want to build one.



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: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3B82789B.8D195045@home.com...
> >
> > Money would help, but unless some white knight shows up with a keen
> interest
> > in the project, I think you have to look elsewhere for motivation. I
> believe
> > that many Ada people would be willing to contribute to any AdaOS project
> that
> > is showing significant progress. You need achievable milestones, otherwise
> > the project just languishes.
> >
> I doubt there is going to be a White Knight who is going to say "I have this
> spare $100m lying around - would you guys build me an OS?" 

Agreed, very doubtful.

> However, if there
> was some carrot held out in the way of a future reward, maybe some people
> would see it as an opportunity to make a few $$$ on the side and devote more
> time to it.

It is easy to agree with this general principle, since none of us hard
working types (on our own time at least!) would deny ourselves some sort
of a reward, even if it were nothing more than to upgrade equipment and
software.  However, I think that in practice, this is going to prove
very difficult to achieve, depending upon the project goals.

>  Putting the OS out under the GPL (or some version thereof) might
> not hold out much hope of money. If it was being developed under some more
> "restrictive" license such that the developers might be able to make some
> $$$ from eventual sales, it might get viewed as a business venture with the
> developers investing in sweat equity.

The attraction of GPL (or licenses similar to it) is simply that your
efforts, and your fellow contributors efforts will always be available
to you for free. I can easily imagine a situation where I might want to
start wwgOS, and have others contribute to it, and myself retire from the
project someday (to work on other things naturally).  I'd still want to
be able to enjoy the efforts of the ongoing efforts, even though mine have
stopped (or moved somewhere else).

If you use a $$ model, then everything becomes more complicated. First of
all, there has to be a fair system of attribution worked out. With a
lot of contributors, this could be a flammable liquid looking for a
spark. $ has a way of changing the way people interact ;-)

> Or if it *must* be GPL (because of
> some religious zeal?) then doing the work under some corporate structure
> wherein contributors are given shares - that is holding out some hope of
> future financial rewards. (Think of the ACT model of selling support. First
> you have to have a product to support!)

I suspect that part of the reason Linux has taken off is due
to it's "free wheeling nature". The GPL is not bad when applied to
an operating system, since your proprietary application is not bound
by the GPL that the O/S might be (although IANAL). The GPL ensures
that all concerned, including the original contributors, have full
access to future versions of it.

It is tempting to say that corporations should pay for it, while making it
available to everyone else for free. Unfortunately, this kills most chances
of it sneaking into the corporation by the back door (as is often done for
FreeBSD/OpenBSD/Linux etc.)

So while I like the idea of $ rewards, I don't believe it will be compatible
with a goal like "AdaOS world domination" ;-)  A better approach might be
to win "world domination" first and then make money from the books 
that you can author and conference talks (since you'll be the 
expert on the subject.) Who knows, you might then later be able to join
a new company like "AdaMeta" ;-)

> > You then have the compiler you need, and you don't even have to fuss with
> > booting issues at this point. The issue at hand, as pointed out above, is
> > to get _something_ working.
> >
> Even if it doesn't have a boot loader and is just run as an "App" at some
> level, you then have at least something that is working. Even under Win2k -
> it could be a kind of "Simulator" program for a while until enough of it got
> built to make it worth doing a boot loader and having it take over the
> machine.

Indeed, you can work out the higher level concepts this way, and obviously
enjoy a more hospitable development environment.

> > I think the "leadership" issue will take care of itself, if someone would
> > just get started on it. But again, as a hobby, I cannot be critical of
> > someone who _wants_ to do a compiler. However, if the goal of this hobby
> > is the OS, then I think that the compiler is just an unnecessary
> diversion.
> > This could be done -after- the OS is getting somewhere. After all, the
> > compiler may need to be different anyway, if the OS is revolutionary
> > (ie. non POSIX in nature).
> >
> Well the "leadership" almost by definition is going to come from whoever it
> is that grabs the bull by the horns and gets something built. That's what
> will set the direction of the project and that individual is who everyone
> else will look to for further direction.

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

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Didier Utheza]

I thonk there is a misunderstanding about the benefit of the project. The
system is under GPL. No direct profit is supposed to be gain from the OS.
I think that if you put money, that means somebody will have to do it. In
consequence this somebody has some right (even if he says no) on the way
the project will evolve. The explosion of Linux was due to the fact that
it was free (free source and 0 kopecks - and this is important: a lot of
programmers went into the project as an hobby and since the kernel of the
project was stirred by Linus, it got somewhere. Now about the GNU
fundation and the Linux project: it is the story of the chicken and the
egg. The GNU developed the essential tools to give some decent clothes to
the kernel and the kernel gave a body to the clothes. One needed the
other). To come back to AdaOS as was said before, the OS has to be
developed now with the tools that are available: GNAT is perfect for that
since at the end it will generate the necessary code. In parallel to the
OS, a C independent compiler (a native compiler as it is Nick's main
project) can be developed and gradually tested on the emerging OS. Both
projects are paramount and as the gcc story showed, if one develops
without the other (at the same time), one of them will go to oblivion
(until some years later, a guy comes with a kernel that it wrote as an
hobby).
Now, all this talk is nice, but it does not involved many people from the
AdaOS project???? Since the Ada list is also the list for the project, I
wonder if it just going to die. Another possibility is that they are
writting some code and don't want to be bother as long as nothing useable
has been written (it is a dream, but it is a good one).
				Didier Utheza.

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Marin David Condic]

There isn't anything wrong with the notion of having money somehow involved
in a project. Granted, if someone comes along with $100m and says "Please
build me an OS", the Golden Rule applies (He who has the gold makes the
rules). Is this somehow "bad"? Notice that Bill Gates did exactly this in
funding the development of WinNT. Say what you will about WinNT and how
good/bad it is relative to other operating systems, but it is not easy to
get around the fact that it is there, it works, and it is installed on
millions of platforms - probably outnumbering Linux installations.
(Existence, functional behavior and installed base are three things AdaOS
does not have at the moment. Hence WinNT is infinitely superior in my mind
and the model on which it got built can't be all bad if it produced an
infinitely superior product.)

Now if a bunch of hobbyists get together and hammer out an OS for fun and it
finds a following, there is nothing wrong with that either. Its just that to
hobbyists, the project is just that - a hobby. No committments to ever
getting anything out there that meets anybody's expectations. If something
comes out of it - great. If it gets tinkered with forever and never produces
anything useful - fine. Nobody is paying anything for it so there is no
committment to anybody to deliver anything and when it stops being fun and
starts to look like work (or other "hobbies" become more interesting, like
gardening or taking the kids to the beach) the whole thing gets put on the
shelf.

The above process is just not one of the more likely ways an OS is going to
get built.

A middle ground exists between Daddy Gatebucks funding an effort and a bunch
of hobbyists doing it for fun and as a labor of love. A bunch of hobbyists
can agree to develop something that might result in sales/services for $$$
and the development is an investment of sweat equity. Suppose 10 guys agree
to build an OS and in exchange for meeting certain project requirements they
each get 1 share in "OS's R Us" - the company that owns the copyright on the
product. If the company ends up making some money - their "hobby" paid off,
didn't it? Hence more incentive to produce something than just doing it
because you have endless love for the hacker community and want to give them
a free OS.

Now does that mean the OS can't be "Open Source"(tm)? I don't think that is
the case. It could be put under the GPL and "OS's R Us" could still make a
buck from the effort. It could also be made "Source Available"(yet-to-be-tm)
meaning that people get the source with a distribution, the source is
available to tinker with, etc., but it doesn't necessarily impart a right to
sell a product based on the source. The "OS's R Us" corporation could sell
the OS (with source) for $29.95 and make a buck that way.

Any number of arrangements are possible with any number of levels of
"Openness" to the end product. My belief is that so long as people see some
possibility in the future of making a few $$$ from their efforts on an OS,
they will likely invest more time and energy in actually producing that OS.
People might do some "charity" work for a while, but sooner or later they
will take their free time elsewhere if they don't see anything coming of
their efforts on a project.

Anybody who thinks otherwise is welcome to come to my house and mow my lawn
free of charge if they like. :-)

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/


"Didier Utheza" <ddutheza@bu.edu> wrote in message
news:Pine.A41.4.10.10108211745510.112048-100000@acs5.bu.edu...
> I thonk there is a misunderstanding about the benefit of the project. The
> system is under GPL. No direct profit is supposed to be gain from the OS.
> I think that if you put money, that means somebody will have to do it. In
> consequence this somebody has some right (even if he says no) on the way
> the project will evolve. The explosion of Linux was due to the fact that
> it was free (free source and 0 kopecks - and this is important: a lot of
> programmers went into the project as an hobby and since the kernel of the
> project was stirred by Linus, it got somewhere. Now about the GNU

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
...
> Any number of arrangements are possible with any number of levels of
> "Openness" to the end product. My belief is that so long as people see some
> possibility in the future of making a few $$$ from their efforts on an OS,
> they will likely invest more time and energy in actually producing that OS.
> People might do some "charity" work for a while, but sooner or later they
> will take their free time elsewhere if they don't see anything coming of
> their efforts on a project.
> 
> Anybody who thinks otherwise is welcome to come to my house and mow my lawn
> free of charge if they like. :-)

Unless I lived across the street from you, and had to look
at your un-mowed lawn, there is no benefit for me to mow 
your lawn for free. ;-)

However the Open Sourced approach means that I can contribute to the
general good, and continue to reap its benefits. This is still "free
labour", but the difference is that I derive some "benefit" from the 
process (my contributions will be propagated and/or improved). You
of course derive the benefit of my contribution as well.

Note however, I am not discouraging "profit" as such, since we all need
that to pay our mortgages with. I just think we need to remember that
some forms of "free labour" do enjoy _real_ defined advantages. Having
free access to GNAT/gcc, Linux/FreeBSD are some that I count as
important.

Consequently, I personally feel that where possible, I should, 
as others have done and continue to do, contribute what I can 
to further these efforts. This helps to keep the "hobby" fun,
and everybody benefits.

Companies of course, _must_ do differently, since the "hobby" 
thing does not fly with the shareholders ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Progress on AdaOS

[Marin David Condic]

I would suggest that what you are talking about looks an awful lot like
"barter". "I'll contribute X and Y and Z if you'll contribute A and B and
C." (And a bunch of other people get a free ride after you've got your
exchange) I have no problem with that and never have said I had a problem
with that. I don't have any problem at all if you write me an OS and hope
that maybe one day I'll write you a compiler. You'll at least get my undying
gratitude. :-) Why you might choose to do so is none of my business and no
matter how hard you try, you won't be able to make me care. :-) You are more
than welcome to put out as much free software as you like and maybe there
are benefits to you because of others having a similar attitude or because
of the satisfaction you get from writing software.

My point can be illustrated by the following two hypothetical propositions:

1) Please come mow my lawn out of the joy you get from spending time in the
sun and the thrill you get looking out the window at my nice tidy yard and
the exercise you get by taking the lawnmower out for a walk. I promise to
say "thank you" and maybe even give you a glass of lemonade when you're
done.

2) Please come mow my lawn because if you do, I'll give you
$1,000,000,000.00, a six-month-long cruise to the Bahamas on your own
private yacht, with your own private, and very accommodating, all-girl crew
who are backed up by a small team of experts who's job it is to dream up new
and interesting ways for them to be nice to you.

Which hypothetical proposition is more likely to attract lawn crews to my
yard this Saturday?

That's what I mean about finding a way to structure a project such that the
participants stand to gain something besides a warm, fuzzy feeling from it.
A partnership of developers that stand to gain some kind of financial reward
from developing an OS are far more likely to produce an OS that works
sometime before Hell freezes over than will a crew of hobbyists who stand to
gain very little from contributing to the project except personal
gratification and the potential to tempt others into writing software they
can use under similar terms.

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/


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B83DE1A.7770DC9C@home.com...
>
> Unless I lived across the street from you, and had to look
> at your un-mowed lawn, there is no benefit for me to mow
> your lawn for free. ;-)
>
> However the Open Sourced approach means that I can contribute to the
> general good, and continue to reap its benefits. This is still "free
> labour", but the difference is that I derive some "benefit" from the
> process (my contributions will be propagated and/or improved). You
> of course derive the benefit of my contribution as well.
>
> Note however, I am not discouraging "profit" as such, since we all need
> that to pay our mortgages with. I just think we need to remember that
> some forms of "free labour" do enjoy _real_ defined advantages. Having
> free access to GNAT/gcc, Linux/FreeBSD are some that I count as
> important.
>
> Consequently, I personally feel that where possible, I should,
> as others have done and continue to do, contribute what I can
> to further these efforts. This helps to keep the "hobby" fun,
> and everybody benefits.
>
> Companies of course, _must_ do differently, since the "hobby"
> thing does not fly with the shareholders ;-)
> --
> Warren W. Gay VE3WWG
> http://members.home.net/ve3wwg

Re: Progress on AdaOS

[Ted Dennison]

In article <9m0rc6$ak0$1@nh.pace.co.uk>, Marin David Condic says...
>My point can be illustrated by the following two hypothetical propositions:
>
>1) Please come mow my lawn out of the joy you get from spending time in the
>sun and the thrill you get looking out the window at my nice tidy yard and
>the exercise you get by taking the lawnmower out for a walk. I promise to
>say "thank you" and maybe even give you a glass of lemonade when you're
>done.
>
>2) Please come mow my lawn because if you do, I'll give you
>$1,000,000,000.00, a six-month-long cruise to the Bahamas on your own
>private yacht, with your own private, and very accommodating, all-girl crew
>who are backed up by a small team of experts who's job it is to dream up new
>and interesting ways for them to be nice to you.
>
>Which hypothetical proposition is more likely to attract lawn crews to my
>yard this Saturday?

Wow! That's just about the most lopsided strawman I've ever seen anybody
construct. I'll be right over. :-)

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

Re: Progress on AdaOS

[Marin David Condic]

Well now that we've established that you're a yard-ape, let's haggle over
the price. :-) (I assume you're familiar with the joke...)

Just goes to show that the bigger the rewards are the more likely the
project will get done.

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:BKSg7.10892$2u.78256@www.newsranger.com...
>
> Wow! That's just about the most lopsided strawman I've ever seen anybody
> construct. I'll be right over. :-)
>

Re: Progress on AdaOS

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> 
> I would suggest that what you are talking about looks an awful lot like
> "barter". "I'll contribute X and Y and Z if you'll contribute A and B and
> C." (And a bunch of other people get a free ride after you've got your
> exchange) 

I suppose that is a way of looking at it.

> My point can be illustrated by the following two hypothetical propositions:
> 
> 1) Please come mow my lawn out of the joy you get from spending time in the
> sun and the thrill you get looking out the window at my nice tidy yard and
> the exercise you get by taking the lawnmower out for a walk. I promise to
> say "thank you" and maybe even give you a glass of lemonade when you're
> done.
> 
> 2) Please come mow my lawn because if you do, I'll give you
> $1,000,000,000.00, a six-month-long cruise to the Bahamas on your own
> private yacht, 

You'd have to show my the money first ;-)

> with your own private, and very accommodating, all-girl crew
> who are backed up by a small team of experts who's job it is to dream up new
> and interesting ways for them to be nice to you.

As a married man, the rest may be "interesting", but otherwise has
no practicle incentive.

> Which hypothetical proposition is more likely to attract lawn crews to my
> yard this Saturday?

I hear ya.

> That's what I mean about finding a way to structure a project such that the
> participants stand to gain something besides a warm, fuzzy feeling from it.
> A partnership of developers that stand to gain some kind of financial reward
> from developing an OS are far more likely to produce an OS that works
> sometime before Hell freezes over than will a crew of hobbyists who stand to
> gain very little from contributing to the project except personal
> gratification and the potential to tempt others into writing software they
> can use under similar terms.

However, as you well know, partnerships can also be complicated. When I
get home from work, I don't like "complicated", but that is just me. ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Progress on AdaOS

[Marin David Condic]

No doubt about it. But I think there are any number of people who might be
much more serious about getting a project done as a commercial, for-profit
endeavor than will get serious over it if it is just a hobby. Hence, even
though partnership schemes, licensing contracts, etc. etc. etc. may be more
complicated than just giving it all away, it probably does a lot to help
move the mission forward.

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/


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B83F894.D7082F9A@home.com...
>
> However, as you well know, partnerships can also be complicated. When I
> get home from work, I don't like "complicated", but that is just me. ;-)

Re: Progress on AdaOS

[David Starner]

On Wed, 22 Aug 2001 15:54:29 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> No doubt about it. But I think there are any number of people who might be
> much more serious about getting a project done as a commercial, for-profit
> endeavor than will get serious over it if it is just a hobby. Hence, even
> though partnership schemes, licensing contracts, etc. etc. etc. may be more
> complicated than just giving it all away, it probably does a lot to help
> move the mission forward.

Prove it. Linux is ample proof of our case. No one's going to argue
that if you give programmers a real salary, you can get an OS. But I
can't think of a single large program that was built on the "no salary;
we'll get money when we're done" shareware model. Show me an OS built
on this model.

I think this is about my last post on the subject. All the talk in the
world won't prove that the ADCL and that model of software licensing
can produce serious large programs. Open source has convinced people it's
actually a usuable model, by demonstration. The ADCL is going to have to
do the same thing before people will buy into it.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Open Source Approach (was Progress on AdaOS)

[Warren W. Gay VE3WWG]

David Starner wrote:
> On Wed, 22 Aug 2001 15:54:29 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> > No doubt about it. But I think there are any number of people who might be
> > much more serious about getting a project done as a commercial, for-profit
> > endeavor than will get serious over it if it is just a hobby. Hence, even
> > though partnership schemes, licensing contracts, etc. etc. etc. may be more
> > complicated than just giving it all away, it probably does a lot to help
> > move the mission forward.
> 
> Prove it. Linux is ample proof of our case. No one's going to argue
> that if you give programmers a real salary, you can get an OS. But I
> can't think of a single large program that was built on the "no salary;
> we'll get money when we're done" shareware model. Show me an OS built
> on this model.

Another thing that does sometimes happen in the "pay for deliverables"
scenario, is that all concerned work until the money runs out, and 
what they deliver in the end is not necessarily what we'd call an 
acceptable deliverable! ;-)  This could be due to many reasons, including
not finished, poor design, poor quality, whatever.

Open Sourced/similar work tends to be different overall, because 
people's reputations and pride are at stake.

The only downside that I can see to the Open Sourced approach is that
the results are sometimes what you might call a "free for all". The
result is sometimes a plethora of new features, which may not be
necessary or desirable. An example of this might be Apache -- a
first rate product in the beginning, but now so full of features that
I'd have trouble trusting it as secure (usually 
more features == more room for exploits).

The other problem is perhaps duplication of effort: for example:

   GNOME vs KDE
   GTK vs Qt
   the various browsers

Yet, OTOH, competition is sometimes good, forcing the best to 
surface to the top.

The one thing that bugs me now is that there are so _many_ different
products for Linux/FreeBSD, that it can be time consuming picking
the best of breed. I wish RedHat or some other organization would 
provide an "Evaluation Service", in order to save us time.

One way it might work, is that you get a 3 point evaluation for free:

   1 - Gotta have
   2 - OK
   3 - Don't bother

but for better grading results, you pay for the service. Something like
the following, or maybe a 10-point system:

   1 - Gotta have
   2 - Excellent
   3 - Above par
   4 - par
   5 - below par
   6 - Poor 
   7 - Don't bother

Additionally, perhaps a "usefulness" measurement. For example, there
must be a ton of "list your directory in colour" scripts, commands and
whatever (usefulness = very low). I hate wasting my time sorting 
through these less useful contributions.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Open Source Approach (was Progress on AdaOS)

[Gerhard Häring]

On Thu, 23 Aug 2001 17:17:04 GMT, Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
>[...]
>The one thing that bugs me now is that there are so _many_ different
>products for Linux/FreeBSD, that it can be time consuming picking
>the best of breed. I wish RedHat or some other organization would 
>provide an "Evaluation Service", in order to save us time.
>
>One way it might work, is that you get a 3 point evaluation for free:
>
>   1 - Gotta have
>   2 - OK
>   3 - Don't bother
>
>but for better grading results, you pay for the service. Something like
>the following, or maybe a 10-point system:
>
>   1 - Gotta have
>   2 - Excellent
>   3 - Above par
>   4 - par
>   5 - below par
>   6 - Poor 
>   7 - Don't bother
>
>Additionally, perhaps a "usefulness" measurement. For example, there
>must be a ton of "list your directory in colour" scripts, commands and
>whatever (usefulness = very low). I hate wasting my time sorting 
>through these less useful contributions.

This feature is now available on freshmeat.net. You can rate the entries.

Sourceforge.net even has a rating system for open-source developers (coding
skills/leadership/...).

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    public key at homepage
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: Open Source Approach (was Progress on AdaOS)

[Warren W. Gay VE3WWG]

Gerhard H�ring wrote:

> On Thu, 23 Aug 2001 17:17:04 GMT, Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> 
>>[...]
>>The one thing that bugs me now is that there are so _many_ different
>>products for Linux/FreeBSD, that it can be time consuming picking
>>the best of breed. I wish RedHat or some other organization would 
>>provide an "Evaluation Service", in order to save us time.
>>
>>One way it might work, is that you get a 3 point evaluation for free:
>>
>>  1 - Gotta have
>>  2 - OK
>>  3 - Don't bother
...


> This feature is now available on freshmeat.net. You can rate the entries.
> 
> Sourceforge.net even has a rating system for open-source developers (coding
> skills/leadership/...).
> 
> Gerhard


This is a start, but this is not really what I had in mind. I'm not
interested in the ratings of the developers, their skills or their
leadership, although they all play a role in the success of the
project.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Progress on AdaOS

[Marin David Condic]

I think you can get pissed off at me as much as you like, but you're putting
words in my mouth and that's not exactly fair.

First off, any number of companies have been started as "garage operations"
developing software with an eye toward "we'll make money on it later"
philosophy. Are you seriously questioning that people start ventures to
build software with no salary but an eye toward making money off of it
later?

Second, for every Open Source success story, you can probably find 10
successful, made for profit, sold for profit, software products under
various other licenses. Proof? Go to CompUSA. Start at one end of the
software sold for profit rack and keep counting until you get to the other
end. Most of what you find there isn't under "Open Source" and even if it
is, someone is sure making a profit by selling it. What's wrong with that?

Third, in this particular case, I have not specifically brought up the
ADCL - I have in fact in other posts indicated that I thought something like
AdaOS could successfully be done under some version of Open Source (probably
any version of the GPL license that you'd be satisfied with) and still be
done "for profit" with the builders of the OS making money off of it. For
some things this makes perfect sense.

My contention here is that things done for profit often have a higher
success rate because people have some kind of financial incentive at stake.
Things done as volunteer, labor of love efforts are not at all prohibited
from being successful, nor should they be banned by law as somehow
intrinsically "evil" - just that they have more of a tendency to languish
because nobody's paycheck or financial future is on the line over it. Why
does that seem to be so mysterious? What is it that takes precidence in most
of our lives? Our jobs or our hobbies? One might find all kinds of
exceptions to this generalization, but I don't think that stops the
generalization from being true.

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" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9m1u2m$baq2@news.cis.okstate.edu...
>
> Prove it. Linux is ample proof of our case. No one's going to argue
> that if you give programmers a real salary, you can get an OS. But I
> can't think of a single large program that was built on the "no salary;
> we'll get money when we're done" shareware model. Show me an OS built
> on this model.
>
> I think this is about my last post on the subject. All the talk in the
> world won't prove that the ADCL and that model of software licensing
> can produce serious large programs. Open source has convinced people it's
> actually a usuable model, by demonstration. The ADCL is going to have to
> do the same thing before people will buy into it.
>

Re: Progress on AdaOS

[David Starner]

On Thu, 23 Aug 2001 14:36:45 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> First off, any number of companies have been started as "garage operations"
> developing software with an eye toward "we'll make money on it later"
> philosophy. Are you seriously questioning that people start ventures to
> build software with no salary but an eye toward making money off of it
> later?

Not Windows-size ventures. Not Microsoft Word size ventures. Especially
not anything that's going to compete against Windows or Word. Every 
company I've thought of that started like that started small - 
GraphicWorkshop for DOS, Wolfenstein 3d. Nothing that would take a number
of programmers many years to complete. 
 
> Second, for every Open Source success story, you can probably find 10
> successful, made for profit, sold for profit, software products under
> various other licenses. Proof? Go to CompUSA. Start at one end of the
> software sold for profit rack and keep counting until you get to the other
> end.

So? Go to CompUSA and count the C/C++ books. More doesn't mean better.

I wasn't attacking for profit software writing in general, either.
I just think there's places where it's no longer feasible.

> My contention here is that things done for profit often have a higher
> success rate because people have some kind of financial incentive at stake.

And several people have pointed out articles that show that's not
necessarily true.

> Things done as volunteer, labor of love efforts are not at all prohibited
> from being successful, nor should they be banned by law as somehow
> intrinsically "evil" - just that they have more of a tendency to languish
> because nobody's paycheck or financial future is on the line over it. 

And what idiot is going to put their financial future on the line over 
AdaOS? Whoever that idiot is, they're going to be starving quickly;
at best, it'll take 5 years for AdaOS to become profitable, assuming they
can budge the Windows/Mac/Unix hegemony in that time (BeOS and OS/2
couldn't, and both were arguably much better operating systems than their
competition.)

> Why
> does that seem to be so mysterious? What is it that takes precidence in most
> of our lives? Our jobs or our hobbies? 

But most of us have jobs, or some other way to feed ourselves. You're claiming
something different; that the small possibility of moderate amounts of money
in the distant future is a strong motivator for people. We've shown articles
that disagree; several people said that it wouldn't personally be a motivater
for them. If it's a motivator for you, go for it. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Ted Dennison]

In article <9m494u$9ic1@news.cis.okstate.edu>, David Starner says...
>
>And what idiot is going to put their financial future on the line over 
>AdaOS? Whoever that idiot is, they're going to be starving quickly;
>at best, it'll take 5 years for AdaOS to become profitable, assuming they

That's a particuarly worthy point. There might be a few people here who would be
willing to use a new OS just because it was written in Ada, but 5 users does not
a success make. For just about anyone else, there are a lot more important
considerations in their choice of OS, like what applications it runs, how nice
the presentation is, how reliable it is, etc. 

Some may claim the the Ada OS will of course be more reliable, but remember that
the coding language is only one factor that goes into reliability. There's also
things like quality of the design, how its implemented, how well tested it is
(which is primiarily a function of *use*). An Ada OS may eventually grow to
become more secure and reliable, all other things being equal. But all other
things will *never* be equal.

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

Re: Progress on AdaOS

[Marin David Condic]

Well, that's asking a whole different question. The question being: "Is
there a market for the OS that you(someone) are proposing to build?" I don't
know that the guys in the AdaOS team have asked that question or done any
research to try to answer it. If one is approaching this project as strictly
a "hobby" and "learning experience" and don't particularly care if anyone
else ever uses the end product, then I suppose the answer doesn't matter
much.

You're right - language of implementation isn't going to be a big deal to
the bulk of the potential users. Anybody proposing to build an OS that they
have hopes of getting adopted by a large community is going to have to have
something to offer that creates some product distinction. For example,
higher reliability, realtime mode, better networking, unique (and superior)
GUI, easier/more powerful API, etc. One would hope that Ada would support
the development of one or more of those sort of distinguishing features, but
it isn't a forgone conclusion.

My feeling is that one useful product distinction that could be built into
an OS for a PC type of machine would be some kind of selectable realtime
mode of execution. Most of the PC/Workstation OS's in use don't do realtime
(for good reasons) and have to either be replaced with a realtime version or
have some kind of "add on" doohickie installed to provide realtime
execution. Being able to say "Yeah, my OS looks/feels similar to Windows (or
Unix or whatever you like) in most respects but you can write a realtime app
and have it make a call to the OS to execute in realtime mode and 'bam!'
you're there!" That would be something to offer that differentiates the
product from the other players out there. Its also a natural playing field
for Ada - hence some justification as to why use Ada 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/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:RVsh7.13233$2u.97927@www.newsranger.com...
> That's a particuarly worthy point. There might be a few people here who
would be
> willing to use a new OS just because it was written in Ada, but 5 users
does not
> a success make. For just about anyone else, there are a lot more important
> considerations in their choice of OS, like what applications it runs, how
nice
> the presentation is, how reliable it is, etc.
>
> Some may claim the the Ada OS will of course be more reliable, but
remember that
> the coding language is only one factor that goes into reliability. There's
also
> things like quality of the design, how its implemented, how well tested it
is
> (which is primiarily a function of *use*). An Ada OS may eventually grow
to
> become more secure and reliable, all other things being equal. But all
other
> things will *never* be equal.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Progress on AdaOS

[Gary Scott]

Hi,
One of my concerns with any new open-source OS is that the vast majority
of those working on such an OS would very likely have very limited
exposure to a variety of systems (we don't need another unix clone). 
Key to making an OS that I would be inclined to use would be a thorough
study/evaluation of past and present OS' such as VMS, VOS, VM, MVS,
RTOS, etc. (showing my own limited exposure) and integrating that
information  into a consistent specification up front.  Simply going off
half cocked and reinventing the wheel isn't usually the best
approach...learn from history.  

There have been a plethora of good multi and single user OS' in the past
that should be well understood for their advantages and disadvantages
before proceeding.

Ted Dennison wrote:
> 
> In article <9m494u$9ic1@news.cis.okstate.edu>, David Starner says...
> >
> >And what idiot is going to put their financial future on the line over
> >AdaOS? Whoever that idiot is, they're going to be starving quickly;
> >at best, it'll take 5 years for AdaOS to become profitable, assuming they
> 
> That's a particuarly worthy point. There might be a few people here who would be
> willing to use a new OS just because it was written in Ada, but 5 users does not
> a success make. For just about anyone else, there are a lot more important
> considerations in their choice of OS, like what applications it runs, how nice
> the presentation is, how reliable it is, etc.
> 
> Some may claim the the Ada OS will of course be more reliable, but remember that
> the coding language is only one factor that goes into reliability. There's also
> things like quality of the design, how its implemented, how well tested it is
> (which is primiarily a function of *use*). An Ada OS may eventually grow to
> become more secure and reliable, all other things being equal. But all other
> things will *never* be equal.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

O/S Research is Dead? (was Progress on AdaOS)

[Warren W. Gay VE3WWG]

Gary Scott wrote:

> Hi,
> One of my concerns with any new open-source OS is that the vast majority
> of those working on such an OS would very likely have very limited
> exposure to a variety of systems (we don't need another unix clone). 
> Key to making an OS that I would be inclined to use would be a thorough
> study/evaluation of past and present OS' such as VMS, VOS, VM, MVS,
> RTOS, etc. (showing my own limited exposure) and integrating that
> information  into a consistent specification up front.  Simply going off
> half cocked and reinventing the wheel isn't usually the best
> approach...learn from history.  
> 
> There have been a plethora of good multi and single user OS' in the past
> that should be well understood for their advantages and disadvantages
> before proceeding.

I just got finished reading an interesting article
in comp.os.research. They pointed to an interesting
paper, which is worth a read :

http://www.cs.bell-labs.com/cm/cs/who/rob/utah2000.ps

It's title is "Software Research is Irrelevant", and it paints a
pessimistic view of why there is no new Operating System research,
and paints a similar picture of computer languages.  While there
seems to be a bit of a Microsoft bias, I think a lot of points
were well made.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Progress on AdaOS

[David Starner]

On Fri, 24 Aug 2001 11:25:08 -0500, Gary Scott wrote:
> There have been a plethora of good multi and single user OS' in the past
> that should be well understood for their advantages and disadvantages
> before proceeding.

It depends on your goal. 

If your goal is to be able to replace the kernel of a Linux/*BSD system
with a kernel written in Ada and leave pretty much everything else the
same (the same way you can interchange the Linux, *BSD and SCO kernels),
then you don't need to study a whole bunch of systems. (I personally
find that an interesting and possibly useful goal.) 

If your goal is to produce a research OS, demonsrating the start of the
art in operating systems and beta/alpha testing all sorts of
experimental features, then of course you need to study all sorts of
operating systems. 

If your goal is to produce a new operating system for the general
public, then making major visible changes is a bad idea, unless there
are huge associated improvements. I use Blackbox under X under Linux; I
find Windows and MacOS and even other X enviroments sometimes annoying,
since they don't react the way I expect. An OS that differed massively
from Unix and Windows probably wouldn't be worth the time for me to wrap
my mind around, unless I was just in the mood to play with a new OS.
(The general public is _never_ in the mood to play with a new OS.) (For
an analogy, would you buy a car where you steered with your feet? Even
if the salesman had dozens of studies from reputable studies showing
that people who had never driven before or had spent four months
training on the new car drove so much better with it?) Dvorak, Shavian
and Deseret (two phonetic alphabets for English) all failed due to this
effect. People don't like to make major changes for relatively minor 
improvements.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Gary Scott]

Hi,

David Starner wrote:
> 
> On Fri, 24 Aug 2001 11:25:08 -0500, Gary Scott wrote:
> > There have been a plethora of good multi and single user OS' in the past
> > that should be well understood for their advantages and disadvantages
> > before proceeding.
> 
> It depends on your goal.

Most certainly.  My goal is to resurrect some of the wonderful
capabilities of OS' past that UNIX fails miserably at.  The most
important one would be real-time control (although far from an ideal OS,
I long for the absolute real-time control and determinism of VOS
(something VMS lacked as well)).  I also long for consistency of design
philosophy rather than the compilation of inconsistently designed grad
student senior projects that is UNIX (and DOS/Win since they are also
highly UNIX centric).  However, my all time favorite OS is VM (not that
VM is a real-time OS).  You can actually run over 50000 independent
guest copies of Linux VMs within VM in one recent IBM test before
interactive (character mode) performance begins to suffer (I think that
was under Z/VM).

> 
> If your goal is to be able to replace the kernel of a Linux/*BSD system
> with a kernel written in Ada and leave pretty much everything else the
> same (the same way you can interchange the Linux, *BSD and SCO kernels),
> then you don't need to study a whole bunch of systems. (I personally
> find that an interesting and possibly useful goal.)
> 
> If your goal is to produce a research OS, demonsrating the start of the
> art in operating systems and beta/alpha testing all sorts of
> experimental features, then of course you need to study all sorts of
> operating systems.
> 
> If your goal is to produce a new operating system for the general
> public, then making major visible changes is a bad idea, unless there
> are huge associated improvements. I use Blackbox under X under Linux; I
> find Windows and MacOS and even other X enviroments sometimes annoying,
> since they don't react the way I expect. An OS that differed massively
> from Unix and Windows probably wouldn't be worth the time for me to wrap
> my mind around, unless I was just in the mood to play with a new OS.
> (The general public is _never_ in the mood to play with a new OS.) (For
> an analogy, would you buy a car where you steered with your feet? Even
> if the salesman had dozens of studies from reputable studies showing
> that people who had never driven before or had spent four months
> training on the new car drove so much better with it?) Dvorak, Shavian
> and Deseret (two phonetic alphabets for English) all failed due to this
> effect. People don't like to make major changes for relatively minor
> improvements.
> 
> --
> David Starner - dstarner98@aasaa.ofe.org
> Pointless website: http://dvdeug.dhis.org
> "I don't care if Bill personally has my name and reads my email and
> laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[David Starner]

On Sat, 25 Aug 2001 12:19:35 -0500, Gary Scott <Gary.L.Scott@lmtas.lmco.com> wrote:
> Most certainly.  My goal is to resurrect some of the wonderful
> capabilities of OS' past that UNIX fails miserably at.  The most
> important one would be real-time control (although far from an ideal OS,
> I long for the absolute real-time control and determinism of VOS
> (something VMS lacked as well)).  I also long for consistency of design
> philosophy rather than the compilation of inconsistently designed grad
> student senior projects that is UNIX (and DOS/Win since they are also
> highly UNIX centric).  However, my all time favorite OS is VM (not that
> VM is a real-time OS).  You can actually run over 50000 independent
> guest copies of Linux VMs within VM in one recent IBM test before
> interactive (character mode) performance begins to suffer (I think that
> was under Z/VM).

But what's your goal? Who are you expecting to use this operating
system? For any desktop system, real-time control is mostly pointless;
is it really a tragedy that my mp3's skip sometimes? Is absolute 
real-time control really the solution to that? Running n guest copies 
of Linux under it is really pointless for a desktop system. At best, I
need one, as an emulator. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Preben Randhol]

On Wed, 22 Aug 2001 16:30:18 GMT, Warren W. Gay VE3WWG wrote:
> 
> Unless I lived across the street from you, and had to look
> at your un-mowed lawn, there is no benefit for me to mow 
> your lawn for free. ;-)
> 
> However the Open Sourced approach means that I can contribute to the
> general good, and continue to reap its benefits. This is still "free
> labour", but the difference is that I derive some "benefit" from the 
> process (my contributions will be propagated and/or improved). You
> of course derive the benefit of my contribution as well.

I would say that it is more like a small community where everybody helps
to build a nice park that everybody can enjoy afterwards.

Preben Randhol
-- 
�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: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Didier Utheza]

I think a good defenition is anarchy, people working for the common good
(anarchy is not chaos). The common good in the case of the free Unixes was
the capability to use and develop professional strength system. The money
factor as an incentive appeared mostly once the sytem proved that it was
able to perform some real work. If not for the people of the free *BSDs
and Linus, and the GNU fundation we will not have something like that
today. They did not received money (besides free willing contribution, GNU
being a special case) at the time they were developing the system. So, the
money with these people is not the main motive to get to work. The dynamic
is different and this is what we need to understand for the AdaOS.
You can have a hobby and work for it seriously. For prof.
programmers/hackers, creating a program is still an art. And this may be
the other type of motivation.
Well, still no news from the AdaOS team.
				Didier Utheza. 

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Preben Randhol]

On Wed, 22 Aug 2001 13:45:23 -0400, Didier Utheza wrote:
> I think a good defenition is anarchy, people working for the common good
> (anarchy is not chaos). The common good in the case of the free Unixes was

Huh? What are you refering to?

> You can have a hobby and work for it seriously. For prof.
> programmers/hackers, creating a program is still an art. And this may be
> the other type of motivation.

For prof. programmers/hackers I guess the main motivation is to get
paid. I mean usually the programmer don't have any relation with the
product he produces as he doesn't use it. When one look at all these
"hobby" projects, the programmers are usually using the end product. I
think that is an important point. I don't say that the programmers
working for money are any worse or anything, but to do something you
really care about usually influences that you do. Those who makes
products that they use themselves while earning money are of course
fortunate.

Preben Randhol
-- 
�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: Progress on AdaOS

[Larry Kilgallen]

In article <9m0rc6$ak0$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> 2) Please come mow my lawn because if you do, I'll give you
> $1,000,000,000.00, a six-month-long cruise to the Bahamas on your own
> private yacht, with your own private, and very accommodating, all-girl crew

Obviously Marin's employment practices are to discriminate against
50% of the population :-).

Re: Progress on AdaOS

[Marin David Condic]

I'm sure that the terms of such a contract can be tailored to what truly
motivates the prospective employee. Not all rewards work equally well for
all people. When it comes to hypothetical employment contracts like this,
I'll let you write your own terms. :-)

Oddly, nobody seemed to be much interested in the first hypothetical
employment contract... Hmmmmmm....... :-)

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@SpamCop.net> wrote in message
news:Ypd7dD0WS5sw@eisner.encompasserve.org...
> In article <9m0rc6$ak0$1@nh.pace.co.uk>, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> writes:
>
> > 2) Please come mow my lawn because if you do, I'll give you
> > $1,000,000,000.00, a six-month-long cruise to the Bahamas on your own
> > private yacht, with your own private, and very accommodating, all-girl
crew
>
> Obviously Marin's employment practices are to discriminate against
> 50% of the population :-).

Re: Progress on AdaOS

[Larry Kilgallen]

In article <9m5p45$7q9$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> My feeling is that one useful product distinction that could be built into
> an OS for a PC type of machine would be some kind of selectable realtime
> mode of execution.

Matching the strongly typed tradition of Ada, I think an operating
system should have strongly typed files, as discussed in:

http://arstechnica.com/reviews/01q3/metadata/metadata-1.html

For those who have better things to do that follow links, it discusses
file metadata and overloading, and particularly whether the datatype
for files is a first class element of metadata or is overloaded onto
the filename.  Naturally the datatype of a file is not Integer vs.
Float, but something like Photoshop Project File vs. Marin's Rocket
Results.

Re: Progress on AdaOS

[Larry Kilgallen]

In article <9m6isb$8201@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:

> If your goal is to produce a new operating system for the general
> public, then making major visible changes is a bad idea, unless there
> are huge associated improvements. I use Blackbox under X under Linux; I
> find Windows and MacOS and even other X enviroments sometimes annoying,
> since they don't react the way I expect. An OS that differed massively
> from Unix and Windows probably wouldn't be worth the time for me to wrap
> my mind around, unless I was just in the mood to play with a new OS.

For me, an OS that resembled either Windows or Unix would not be of
interest.  The only thing that would interest me in an experimental
operating system is if it had significant new capablities.

Thus Linux wasn't it.  I never saw BeOS or NexT -- perhaps they were it.

> (The general public is _never_ in the mood to play with a new OS.) (For
> an analogy, would you buy a car where you steered with your feet?

Yes, but for some of us, Unix is like steering with your feet.
I understand that David feels the opposite.  My point is not
to win him over, but to point out there is no unanimity.

Re: Progress on AdaOS

[David Starner]

On 24 Aug 2001 20:31:15 -0500, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
> In article <9m6isb$8201@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:
> 
> Thus Linux wasn't it.  I never saw BeOS or NexT -- perhaps they were it.

I don't know what you consider major significant changes. From what
I've read of NeXT, it was distinctly a Unix that's been mostly eclipsed 
by Linux. I've played a little with BeOS; it's a very nice system that's
fairly distinct from other systems. It's not _quite_ dead yet - I believe
you can still download a full personal version for ix86 from BeOS, if
you have a Windows or Linux system sitting around. (See free.be.com). 
The API is C++; I don't know if you'll consider that better or worse than
the more common C APIs. 
 
>> (The general public is _never_ in the mood to play with a new OS.) (For
>> an analogy, would you buy a car where you steered with your feet?
> 
> Yes, but for some of us, Unix is like steering with your feet.
> I understand that David feels the opposite.  My point is not
> to win him over, but to point out there is no unanimity.

There's no unanimity in computer people. The only numbers for VMS I could 
find on the WWW was a "hundreds of thousands" of users. Is there any non-Unix,
non-Windows, non-Macintosh OSs out there bigger than VMS? Linux has 8 to 10
million users, Mac has probably three times that, and Windows probably has
at least a couple hundred million users. Over 99.4% is pretty close to 
unanimity among the general public.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Gary Scott]

Hi,

David Starner wrote:
> 
> On 24 Aug 2001 20:31:15 -0500, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
> > In article <9m6isb$8201@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:
> >
> > Thus Linux wasn't it.  I never saw BeOS or NexT -- perhaps they were it.
> 
> I don't know what you consider major significant changes. From what
> I've read of NeXT, it was distinctly a Unix that's been mostly eclipsed
> by Linux. I've played a little with BeOS; it's a very nice system that's
> fairly distinct from other systems. It's not _quite_ dead yet - I believe
> you can still download a full personal version for ix86 from BeOS, if
> you have a Windows or Linux system sitting around. (See free.be.com).
> The API is C++; I don't know if you'll consider that better or worse than
> the more common C APIs.
> 
> >> (The general public is _never_ in the mood to play with a new OS.) (For
> >> an analogy, would you buy a car where you steered with your feet?
> >
> > Yes, but for some of us, Unix is like steering with your feet.
> > I understand that David feels the opposite.  My point is not
> > to win him over, but to point out there is no unanimity.
> 
> There's no unanimity in computer people. The only numbers for VMS I could
> find on the WWW was a "hundreds of thousands" of users. Is there any non-Unix,
> non-Windows, non-Macintosh OSs out there bigger than VMS? Linux has 8 to 10
> million users, Mac has probably three times that, and Windows probably has
> at least a couple hundred million users. Over 99.4% is pretty close to
> unanimity among the general public.

MVS surely qualifies as surpassing VMS in total numbers of users, we
have several hundred thousands at my company alone (although some don't
realize that they're using it because it's hidden behind a nifty GUI). 
Last estimate that I saw for VM was that there were 8 to 10 million
users world wide (similar figures for OS/2).  I'm sure that's declined
(in both cases), but virtually every large company that has a mainframe
in their accounting department has a VM system in addition to MVS or
OS/390.  But then, every OS survey I've seen conveniently discounts
mainframe usage altogether.  We also have probably several hundred VOS
users in house (we may be the last ones in the known universe however).

> 
> --
> David Starner - dstarner98@aasaa.ofe.org
> Pointless website: http://dvdeug.dhis.org
> "I don't care if Bill personally has my name and reads my email and
> laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Gary Scott]

Hi,
Sorry, I meant to say around 100 VOS users rather than several 100.

Gary Scott wrote:
> 
> Hi,
> 
> David Starner wrote:
> >
> > On 24 Aug 2001 20:31:15 -0500, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
> > > In article <9m6isb$8201@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:
> > >
> > > Thus Linux wasn't it.  I never saw BeOS or NexT -- perhaps they were it.
> >
> > I don't know what you consider major significant changes. From what
> > I've read of NeXT, it was distinctly a Unix that's been mostly eclipsed
> > by Linux. I've played a little with BeOS; it's a very nice system that's
> > fairly distinct from other systems. It's not _quite_ dead yet - I believe
> > you can still download a full personal version for ix86 from BeOS, if
> > you have a Windows or Linux system sitting around. (See free.be.com).
> > The API is C++; I don't know if you'll consider that better or worse than
> > the more common C APIs.
> >
> > >> (The general public is _never_ in the mood to play with a new OS.) (For
> > >> an analogy, would you buy a car where you steered with your feet?
> > >
> > > Yes, but for some of us, Unix is like steering with your feet.
> > > I understand that David feels the opposite.  My point is not
> > > to win him over, but to point out there is no unanimity.
> >
> > There's no unanimity in computer people. The only numbers for VMS I could
> > find on the WWW was a "hundreds of thousands" of users. Is there any non-Unix,
> > non-Windows, non-Macintosh OSs out there bigger than VMS? Linux has 8 to 10
> > million users, Mac has probably three times that, and Windows probably has
> > at least a couple hundred million users. Over 99.4% is pretty close to
> > unanimity among the general public.
> 
> MVS surely qualifies as surpassing VMS in total numbers of users, we
> have several hundred thousands at my company alone (although some don't
> realize that they're using it because it's hidden behind a nifty GUI).
> Last estimate that I saw for VM was that there were 8 to 10 million
> users world wide (similar figures for OS/2).  I'm sure that's declined
> (in both cases), but virtually every large company that has a mainframe
> in their accounting department has a VM system in addition to MVS or
> OS/390.  But then, every OS survey I've seen conveniently discounts
> mainframe usage altogether.  We also have probably several hundred VOS
> users in house (we may be the last ones in the known universe however).
> 
> >
> > --
> > David Starner - dstarner98@aasaa.ofe.org
> > Pointless website: http://dvdeug.dhis.org
> > "I don't care if Bill personally has my name and reads my email and
> > laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[David Starner]

Can you please trim the message a little more?

On Sat, 25 Aug 2001 14:34:35 -0500, Gary Scott wrote:
> MVS surely qualifies as surpassing VMS in total numbers of users, we
> have several hundred thousands at my company alone (although some don't
> realize that they're using it because it's hidden behind a nifty GUI). 
> Last estimate that I saw for VM was that there were 8 to 10 million
> users world wide (similar figures for OS/2).  I'm sure that's declined
> (in both cases), but virtually every large company that has a mainframe
> in their accounting department has a VM system in addition to MVS or
> OS/390.  But then, every OS survey I've seen conveniently discounts
> mainframe usage altogether.  

If it's hidden behind a nifty GUI, do they really count as users of
the OS? I mean, I use all sorts of OS's everyday hidden behind a
(not quite so nifty) GUI known as a web browser. But the OS on the
other side of that link concerns me not. If that nifty GUI is done
right, the OS behind it could change from MVS to Unix to NT to MacOS X
and the end user would never know.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Larry Kilgallen]

In article <9maa90$aik2@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:
> Can you please trim the message a little more?
> 
> On Sat, 25 Aug 2001 14:34:35 -0500, Gary Scott wrote:
>> MVS surely qualifies as surpassing VMS in total numbers of users, we
>> have several hundred thousands at my company alone (although some don't
>> realize that they're using it because it's hidden behind a nifty GUI). 
>> Last estimate that I saw for VM was that there were 8 to 10 million
>> users world wide (similar figures for OS/2).  I'm sure that's declined
>> (in both cases), but virtually every large company that has a mainframe
>> in their accounting department has a VM system in addition to MVS or
>> OS/390.  But then, every OS survey I've seen conveniently discounts
>> mainframe usage altogether.  
> 
> If it's hidden behind a nifty GUI, do they really count as users of
> the OS? I mean, I use all sorts of OS's everyday hidden behind a
> (not quite so nifty) GUI known as a web browser. But the OS on the
> other side of that link concerns me not. If that nifty GUI is done
> right, the OS behind it could change from MVS to Unix to NT to MacOS X
> and the end user would never know.

Under that rule, there are no Macintosh users.

Re: Progress on AdaOS

[David Starner]

On 26 Aug 2001 06:47:21 -0500, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
> In article <9maa90$aik2@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:
>> On Sat, 25 Aug 2001 14:34:35 -0500, Gary Scott wrote:
>>> MVS surely qualifies as surpassing VMS in total numbers of users, we
>>> have several hundred thousands at my company alone (although some don't
>>> realize that they're using it because it's hidden behind a nifty GUI). 
>> 
>> If it's hidden behind a nifty GUI, do they really count as users of
>> the OS? I mean, I use all sorts of OS's everyday hidden behind a
>> (not quite so nifty) GUI known as a web browser. But the OS on the
>> other side of that link concerns me not. If that nifty GUI is done
>> right, the OS behind it could change from MVS to Unix to NT to MacOS X
>> and the end user would never know.
> 
> Under that rule, there are no Macintosh users.

You think that Macintosh users don't realize that they're using a 
Macintosh? I was talking about people who use the system through a
specialized application. If it puts a whole GUI on the level of the
Macintosh or Windows, then it wouldn't be hidden - unless it completely
emulated the Macintosh or Windows GUI, in which it wouldn't be nifty.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Frédéric Valdes]

David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:


> > 
> > Under that rule, there are no Macintosh users.
> 
> You think that Macintosh users don't realize that they're using a 
> Macintosh? I was talking about people who use the system through a
> specialized application. If it puts a whole GUI on the level of the
> Macintosh or Windows, then it wouldn't be hidden - unless it completely
> emulated the Macintosh or Windows GUI, in which it wouldn't be nifty.

Carbon applications works as well in mac OS 9 as in Mac OS X.

They are an example of typical mac applications that obey to the
guidelines of Apple. This kind of application is unique. 

It uses natively the multitask, the multithread and the executable
format is the same.

The differences between the two runtime environment are the presence of
the preemptively scheduled task and the protected memory in mac OS X and
the cooperatively scheduled task in mac OS 9.
It is the only difference. And both run at the same speed in the two
environment without a recompilation.

Mac OS X is a UNIX(rewritten on the base of freeBSD and NeXTStep) but
users still have the feeling they use a macintosh.

The only problem is that most of carbon procedures aren't reentrant. It
is the only problem. But mac OS 9 was a multiproc-able system.

There is an other problem: I don't know if Apple's gcc 3.0 can compile
Ada source with GNAT...

All my excuses for the bad english.

-- 
Ca fait bien longtemps qu'on croit aller loin.
Maintenant y'a des v�los dans les salles de bain...
-+- In Matmatah la Ouache -+-

Re: Progress on AdaOS

[Marin David Condic]

Well, in an imaginary OS written in Ada, it would be interesting to develop
a unique file system as well. One thing to keep in mind is that the file
system is essentially independent of the core operating system. You could
build the OS in such a way that it could access Unix, VMS, Windows, Mac,
and/or its own file system so long as it knew what it was looking at. There
would be advantages to a file system (like what is on the Mac) that contains
more than just some raw bytes of data - but you give something up at the
same time. Its harder to treat files like that as just raw data. (IIRC, the
advice we once got from DEC on trying to duplicate the "copy" command
programatically was to not bother trying to do that. It was just too hard to
account for everything that "copy" had to do to deal with all the variety of
file types.)

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@SpamCop.net> wrote in message
news:uBW9YP9YCoMO@eisner.encompasserve.org...
>
> Matching the strongly typed tradition of Ada, I think an operating
> system should have strongly typed files, as discussed in:
>
> http://arstechnica.com/reviews/01q3/metadata/metadata-1.html
>
> For those who have better things to do that follow links, it discusses
> file metadata and overloading, and particularly whether the datatype
> for files is a first class element of metadata or is overloaded onto
> the filename.  Naturally the datatype of a file is not Integer vs.
> Float, but something like Photoshop Project File vs. Marin's Rocket
> Results.

Re: Progress on AdaOS

[David Starner]

On Mon, 27 Aug 2001 09:14:53 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> Well, in an imaginary OS written in Ada, it would be interesting to develop
> a unique file system as well. One thing to keep in mind is that the file
> system is essentially independent of the core operating system. You could
> build the OS in such a way that it could access Unix, VMS, Windows, Mac,
> and/or its own file system so long as it knew what it was looking at. There
> would be advantages to a file system (like what is on the Mac) that contains
> more than just some raw bytes of data - but you give something up at the
> same time. Its harder to treat files like that as just raw data. 

I was thinking about the metadata article, and my experiances with the
'raw data' Unix and semi-quasi-metadata Windows. I think the metadata
needs to be hierachial. Everything can viewed as raw data. Then we have
for example, types text, image, video, audio, program, data and
text/utf8, text/utf8/crlf, text/utf8/lf, text/utf8/psls, image/png,
image/tiff, image/tiff/lzw, data/word, data/word/7.0, etc.  So programs
like copy can deal with them on the raw data level, grep could deal with
text files, and pngcrush could deal with image/png. It'd be nice to be
able to open an image file, and not worry about the format.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Darren New]

> I was thinking about the metadata article, and my experiances with the
> 'raw data' Unix and semi-quasi-metadata Windows. I think the metadata
> needs to be hierachial.

Actually, my thought about the article was that it was obviously written
as a big justification for the idea that the Mac OS shouldn't put file
creator types as part of the file name. All the rest of it was either
obvious or pointless, or a needless assumption. (IMHO, that is.)

For example, it starts off with an assumption that files are named
entities, buckets of bits that need interpretation by disassociated
program code. This isn't true of "objects" in the OO sense, nor is it
true of processes, nor is it true of RPCs.

If there were an AdaOS that didn't allow one to declare a passive
partition and say "Hey, this is the data", I'd be disappointed. Why
*can't* my "file" have a directed acyclic graph of tagged records
holding access values in it?

> Everything can viewed as raw data.

Well, no. Only if you come from the Unix/Windows/CPM world. (Not even
there, actually. What's the "raw data" in the superblock? In a
directory? In a network-mounted partition?)

Those of us who had the privledge of (for example) using ISAM files so
you could actually insert a line of text at the beginning of your file
without rewriting the whole file can tell you that not everything is raw
data. :-)

> Then we have
> for example, types text, image, video, audio, program, data and
> text/utf8, text/utf8/crlf, text/utf8/lf, text/utf8/psls, image/png,
> image/tiff, image/tiff/lzw, data/word, data/word/7.0, etc. 

How about the type for Ada source files? Ada specification headers? Ada
bodies? The type for an "Active Server Page" with Ada code embedded in
HTML markup under control of CVS? And how do you determine which
programs can read such? :-)

> So programs
> like copy can deal with them on the raw data level,

Only in the most primitive of systems does that work. Does copy *really*
deal with transfering text files across a TCP link between a unix box
and a mac box? No, it's the device drivers.

Anyway, I'd think making a persistant Ada-typed store would be a great
file system for an Ada-based OS. Then you could have utilities to copy
Text_IO-based files to whatever internal format you wanted (such as
"editable text").

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[David Starner]

On Mon, 27 Aug 2001 21:08:27 GMT, Darren New <dnew@san.rr.com> wrote:
> For example, it starts off with an assumption that files are named
> entities, buckets of bits that need interpretation by disassociated
> program code. This isn't true of "objects" in the OO sense, nor is it
> true of processes, nor is it true of RPCs.

That would be why objects, processes and RPCs aren't files.

> If there were an AdaOS that didn't allow one to declare a passive
> partition and say "Hey, this is the data", I'd be disappointed. Why
> *can't* my "file" have a directed acyclic graph of tagged records
> holding access values in it?

An OS could certainly flatten that into a file. It would probably
take a lot of work to make sure it wasn't an OS/program/libada specific
file, though.
 
>> Everything can viewed as raw data.
> 
> Well, no. Only if you come from the Unix/Windows/CPM world. (Not even
> there, actually. What's the "raw data" in the superblock? In a
> directory? In a network-mounted partition?)

Those aren't files. However, the fact that /dev/hda (Hard drive 1) could
be viewed as a file was a life saver for me. After I wiped out my partition
table, I managed to retrive the text on that partition with the strings
utility. 
 
> Those of us who had the privledge of (for example) using ISAM files so
> you could actually insert a line of text at the beginning of your file
> without rewriting the whole file can tell you that not everything is raw
> data. :-)

When is that much of a win? I don't play around with files large enough
for this to matter very often. 
 
>> Then we have
>> for example, types text, image, video, audio, program, data and
>> text/utf8, text/utf8/crlf, text/utf8/lf, text/utf8/psls, image/png,
>> image/tiff, image/tiff/lzw, data/word, data/word/7.0, etc. 
> 
> How about the type for Ada source files? Ada specification headers? Ada
> bodies? 

text/ada or text/utf8/ada or text/utf8/foo/ada. (On second thought, dictate
that all text on the system be UTF-8 with a standard line ending (LF, CRLF,
PS/LS, it doesn't matter so long as it's consistent.) Then we can ignore this
/utf8/foo/ stuff.)

> The type for an "Active Server Page" with Ada code embedded in
> HTML markup under control of CVS? 

text/x-asp.

> And how do you determine which
> programs can read such? :-)

Any program that can read raw data, or text, or text/ada. 

I'm not sure I understand your point. These are problems for all
tagged type systems, but you don't seem to want raw data either.
 
>> So programs
>> like copy can deal with them on the raw data level,
> 
> Only in the most primitive of systems does that work. Does copy *really*
> deal with transfering text files across a TCP link between a unix box
> and a mac box? No, it's the device drivers.

It's always the device drivers. Even in MS/DOS, copy called the OS to
actually write the file. But if the mac box looks like a directory to
copy, then copy copies it there, regardless of the underlying mechanism
to put data in that directory.
 
> Anyway, I'd think making a persistant Ada-typed store would be a great
> file system for an Ada-based OS. Then you could have utilities to copy
> Text_IO-based files to whatever internal format you wanted (such as
> "editable text").

Yuck. Text_IO files should _be_ editable text. Text should be text should
be text. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Darren New]

> That would be why objects, processes and RPCs aren't files.

Why not? Again, you're starting with a preconceived notion of "file"
being "an array of bytes", then claiming that the OS should be handling
that as the basic type.

Indeed, RPCs *can* be files. It's called a CGI script. Objects can be
files. It's called an OO Database. Processes can be files. It's called
/proc. Etc.

<TotalRecall> Open your miiiiind.... </TotalRecall> ;-)

For example, on the Amiga OS, files were tasks, as were device drivers,
etc. You could send a message to a file task to read and write portions
of the file into particular buffers, and when the message returned, the
I/O was complete. This allowed you to treat windows as files
(open("con:top/left/width/height/title")) and such. It allowed you to
write phenomes to the voice synthesizer and read lip positions back as
the sound was generated. Cool stuff like that.

Imagine an OS where "files" are actually protected objects, fully typed,
that outlive your program's execution. Directories are simply persistant
protected objects that act as arrays mapping strings to these "files".

> > If there were an AdaOS that didn't allow one to declare a passive
> > partition and say "Hey, this is the data", I'd be disappointed. Why
> > *can't* my "file" have a directed acyclic graph of tagged records
> > holding access values in it?
> 
> An OS could certainly flatten that into a file. It would probably
> take a lot of work to make sure it wasn't an OS/program/libada specific
> file, though.

I don't see any particular need to flatten it as such. Again, you're
trying to map "files" onto "array of bytes in a UNIX-like file system".
That's not the point.

> >> Everything can viewed as raw data.
> >
> > Well, no. Only if you come from the Unix/Windows/CPM world. (Not even
> > there, actually. What's the "raw data" in the superblock? In a
> > directory? In a network-mounted partition?)
> 
> Those aren't files. 

My point is to ask why not. My point is to ask "why limit yourself to
array-of-byte files" and you're answering "because anything else is not
a file." That's not helpful.

> > Those of us who had the privledge of (for example) using ISAM files so
> > you could actually insert a line of text at the beginning of your file
> > without rewriting the whole file can tell you that not everything is raw
> > data. :-)
> 
> When is that much of a win? I don't play around with files large enough
> for this to matter very often.

Put it this way. Let's say files were just numbered in a directory,
rather than having meaningful textual names. When you deleted file 5,
all the files from 6 up to whatever got renumbered. Is it reasonable to
say "why's that a problem? I only work with small directories."

There's a reason folks put names on files, on procedures, on users. The
same reason holds for individual pieces of data in a file. It's a win
whenever you store more than one piece of data in a file, like more than
one line in a text file, more than one user in a password file, etc. And
if you're only storing one atomic piece of data in a file, it's because
you're using the file's name as an index anyway. Have you never written
a program where the name of a file is calculated by the program?
"Image01.jpg", "Image02.jpg", ...?

And yes, it *is* a problem for large files, or folks wouldn't have
invented the DBM stuff to hold /etc/passwd in a hashed file, and they
wouldn't have rewritten directories to no longer be linearly searched. 
Same thing.

If you've never used a system where there are keys on the data records,
you might not understand why it's useful. On the other hand, if you've
only ever used FORTH, where the disk is organized as a numbered array of
sectors, you might not appriciate the charm that having directories and
file names supplies.
 
> > The type for an "Active Server Page" with Ada code embedded in
> > HTML markup under control of CVS?
> 
> text/x-asp.

And how does CVS know it can handle this, and how does the web browser
know it needs to invoke the Ada compiler and not the Java compiler when
rebuilkding this page?
 
> > And how do you determine which
> > programs can read such? :-)
> 
> Any program that can read raw data, or text, or text/ada.
> 
> I'm not sure I understand your point. These are problems for all
> tagged type systems, but you don't seem to want raw data either.

The point is that no passive tagging system is going to be complete
enough that you can specify everything you need to know about the
program in the type tag. Just like every permission system needs
something along the lines of setuid to let you do very specific things
with very specific files that you otherwise couldn't do.

My point is that a persistant data storage system modelled as named
arrays of bytes is just primitive. The addition of type tags tells you
what library to use to understand the interpretation of the untyped
array of bytes, which is just silly when you start trying to use it from
a language like Ada that actually has real types.

> It's always the device drivers. Even in MS/DOS, copy called the OS to
> actually write the file. But if the mac box looks like a directory to
> copy, then copy copies it there, regardless of the underlying mechanism
> to put data in that directory.

Errr... When talking about designing and writing an OS, saying "oh,
don't worry, the device drivers will take care of it" doesn't work.

In any case, a program like "copy" can only copy raw data if the raw
data is primitive. If, for example, you have semantically significant
record boundaries on a tape, and you copy it over TCP, you're going to
lose those boundaries. If you have (say) a database file with pointers
to disk blocks embedded in it, and you copy that file to another place
on the disk, you need to fix those disk block pointers. Etc.
 
> > Anyway, I'd think making a persistant Ada-typed store would be a great
> > file system for an Ada-based OS. Then you could have utilities to copy
> > Text_IO-based files to whatever internal format you wanted (such as
> > "editable text").
> 
> Yuck. Text_IO files should _be_ editable text. Text should be text should
> be text.

Text_IO files aren't editable. There's no way to (say) insert text at
the beginning. There's no way to change text in the middle. Nobody
writes a text editor (at least under an array-of-characters file system)
that doesn't suck the file into a different data structure for editing
and then write it back out. That different data structure is what I'm
talking about. Why not make *that* persistant, and have Text_IO be the
"portability" level. I.e., why insist that "stream" are the "real" data,
and everything else is just this temporary copy inside a program? Why
not let the real data be the one with the pointers and strong types and
such, and only use streams when you want to communicate with a different
OS?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[David Starner]

On Tue, 28 Aug 2001 16:13:42 GMT, Darren New <dnew@san.rr.com> wrote:
> My point is to ask why not. My point is to ask "why limit yourself to
> array-of-byte files" and you're answering "because anything else is not
> a file." That's not helpful.

The way I feel, you keeping asking "why limit yourself to citrus fruits
as oranges" and I'm answering "because anything else isn't an orange."
Until you give me a concrete definition for a file, this discussion
isn't going anywhere.

No matter how you define it, most files are arrays of bytes. Look up
how hard drives and RAM work if you don't believe me.

> Why not? Again, you're starting with a preconceived notion of "file"
> being "an array of bytes", then claiming that the OS should be handling
> that as the basic type.

I don't even know what you mean by "the basic type" here.
 
> For example, on the Amiga OS, files were tasks, as were device drivers,
> etc. You could send a message to a file task to read and write portions
> of the file into particular buffers, and when the message returned, the
> I/O was complete. This allowed you to treat windows as files
> (open("con:top/left/width/height/title")) and such. It allowed you to
> write phenomes to the voice synthesizer and read lip positions back as
> the sound was generated. Cool stuff like that.

And, wow, open ("con:1/1/20/20/My Window / file") is so much clearer than
Create_Window (Top => 1, Left => 1, Width => 20, Height => 20, 
Title => "My Window / file"). Oops, we need to escape the / somehow
in your call, don't we . . .
 
You're welcome to open a pipe to the voice synthesizer. It'll work
just as well.

> Imagine an OS where "files" are actually protected objects, fully typed,
> that outlive your program's execution. Directories are simply persistant
> protected objects that act as arrays mapping strings to these "files".

So we have an space-inefficent tangle of data that's hard to transfer 
between systems running different OS's and probably even between different 
programs on the same system.
 
>> An OS could certainly flatten that into a file. It would probably
>> take a lot of work to make sure it wasn't an OS/program/libada specific
>> file, though.
> 
> I don't see any particular need to flatten it as such. Again, you're
> trying to map "files" onto "array of bytes in a UNIX-like file system".
> That's not the point.

Hard drives, CDs, floppies and tapes are flat. Hence to store it you're
going to need to flatten it.
 
> There's a reason folks put names on files, on procedures, on users. The
> same reason holds for individual pieces of data in a file. It's a win
> whenever you store more than one piece of data in a file, like more than
> one line in a text file, more than one user in a password file, etc. And
> if you're only storing one atomic piece of data in a file, it's because
> you're using the file's name as an index anyway. Have you never written
> a program where the name of a file is calculated by the program?
> "Image01.jpg", "Image02.jpg", ...?

And how much of a win is storing that in one file over storing it in
a directory and tarring / zipping it for transport? 

>> > The type for an "Active Server Page" with Ada code embedded in
>> > HTML markup under control of CVS?
>> 
>> text/x-asp.
> 
> And how does CVS know it can handle this, 

text/*

> and how does the web browser
> know it needs to invoke the Ada compiler and not the Java compiler when
> rebuilkding this page?

I would assume it reads the start of the file. 
  
> The point is that no passive tagging system is going to be complete
> enough that you can specify everything you need to know about the
> program in the type tag. 

Sure. And?

> My point is that a persistant data storage system modelled as named
> arrays of bytes is just primitive. The addition of type tags tells you
> what library to use to understand the interpretation of the untyped
> array of bytes, which is just silly when you start trying to use it from
> a language like Ada that actually has real types.

I've used Ada. Every so often in Ada, you're juggling twenty different
types and having to constantly convert between them. I fail to see the
advantage to that in an OS. I don't want each program having its own 
set of types that are incompatible with everything else. I also want
my editor to work any appropriate file, be it C, Ada, HTML, Tex, 
a diary, whatever.

You ask how the web browser knows it needs to invoke the Ada compiler
in my situation. How does the web browser know anything about the
file in your situation? How does this type get created? What happens
if you change it from Ada to Chill? How does the editor know what type
to create?
 
> Errr... When talking about designing and writing an OS, saying "oh,
> don't worry, the device drivers will take care of it" doesn't work.

Sure it does. It's called stratifaction. When talking about user mode
utilities, we can hand certain things off to the kernel, and let
the kernel worry about it.
 
> Why
> not let the real data be the one with the pointers and strong types and
> such, and only use streams when you want to communicate with a different
> OS?

Because a plain text file is readable by 4 million different programs.
Because the format for PNG is set in stone and readable by 40,000 different
programs. However, the internal format for Emacs has been known to change
between versions. It's hard to keep internal structures the same; much
easier to conform to a consistent external standard.

Also, I've worked with programs that used a database and those that use
plain text files, and the latter seem more reliable. I got semi-regular
database corruptions on GURU, whereas I never heard of one on GCA, and
one on GCA probably would have been confined to one or two files and those
could have been edited in Notepad. I've fixed a corruption in dpkg's
available file with vim, whereas a binary database I would have had to
reinstall and lose the data in the file. (Of course, that's probably part 
of the reason dpkg is so slow.)

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Darren New]

David Starner wrote:
> 
> On Tue, 28 Aug 2001 16:13:42 GMT, Darren New <dnew@san.rr.com> wrote:
> > My point is to ask why not. My point is to ask "why limit yourself to
> > array-of-byte files" and you're answering "because anything else is not
> > a file." That's not helpful.
> 
> The way I feel, you keeping asking "why limit yourself to citrus fruits
> as oranges" and I'm answering "because anything else isn't an orange."
> Until you give me a concrete definition for a file, this discussion
> isn't going anywhere.

A file would be a collection of data that can be shared between programs
and outlasts any given process. (Of course, if it's represented as a
process, it doesn't outlast the process that it is, but that's no
different than saying a file doesn't persist past the execution of the
"rm" program.)

Note, for example, that a shared memory segment falls into this model,
even under UNIX.

Now imagine taking the UNIX shared-memory-segment model, and expanding
it to be a shared-tagged-object model. You do whatever manipulations you
want, and your allocations all come from a storage pool that deals with
the stuff as a file.

> No matter how you define it, most files are arrays of bytes. Look up
> how hard drives and RAM work if you don't believe me.

Actually, most files are *not* arrays of bytes. Most files are arrays of
records, excluding compressed files (records being 1 bit long) and
streaming media perhaps. Under CP/M, files were arrays of sectors. Line
printers aren't arrays of bytes. The mouse isn't an array of bytes.
/dev/audio isn't an array of bytes. Fonts aren't arrays of bytes. For
that matter, images aren't arrays of bytes either, they're 3D arrays of
pixels. You just serialize them into arrays of bytes.

Which is irrelevant, considering that we seem to have no problem storing
the kinds of complex pointer-based information I'm talking about in RAM,
which is an array of bytes, almost.  (Note, no RAM is *not* an array of
bytes either, on any hardware with memory management.)

> > Why not? Again, you're starting with a preconceived notion of "file"
> > being "an array of bytes", then claiming that the OS should be handling
> > that as the basic type.
> 
> I don't even know what you mean by "the basic type" here.

The fundamental type of data handled by the OS. In UNIX, there's four
fundamental types of data in files: files, dirs, block-special, and
character-special.
 
> > For example, on the Amiga OS, files were tasks, as were device drivers,
> > etc. You could send a message to a file task to read and write portions
> > of the file into particular buffers, and when the message returned, the
> > I/O was complete. This allowed you to treat windows as files
> > (open("con:top/left/width/height/title")) and such. It allowed you to
> > write phenomes to the voice synthesizer and read lip positions back as
> > the sound was generated. Cool stuff like that.
> 
> And, wow, open ("con:1/1/20/20/My Window / file") is so much clearer than
> Create_Window (Top => 1, Left => 1, Width => 20, Height => 20,
> Title => "My Window / file"). 

Uh huh. And /dev/fd0 is so much clearer than INT21 calls, yes? The point
is that windows were consistant with the file paradigm in ways that they
aren't consistant in X-Windows, and this was possible because they were
based on active processes with complex data rather than on stuff built
into the kernel.

> Oops, we need to escape the / somehow
> in your call, don't we . . .

No, because the title came last. Also irrelevant. I can see it's
pointless for me to give counterexamples to your points if you're going
to actively attempt to ignore why I might be giving such
counterexamples.

> You're welcome to open a pipe to the voice synthesizer. It'll work
> just as well.

No, it won't, for reasons that are irrelevant to Ada so I won't persue
here.
 
> > Imagine an OS where "files" are actually protected objects, fully typed,
> > that outlive your program's execution. Directories are simply persistant
> > protected objects that act as arrays mapping strings to these "files".
> 
> So we have an space-inefficent tangle of data that's hard to transfer
> between systems running different OS's and probably even between different
> programs on the same system.

It would be easy to transfer them between programs on the same OS, I
would think. At least, if those programs were written in Ada or
compatible with them. It's easy to move them to a different system: You
serialize them. But why make serialization a *required* step *every*
time you use a file, *including* the ones you have no intention of ever
moving to any other system?

Doing so is like using overlays instead of demand paging for your memory
management. Why would you, when you can build it into the OS and get
everyone using it for free?
 
> >> An OS could certainly flatten that into a file. It would probably
> >> take a lot of work to make sure it wasn't an OS/program/libada specific
> >> file, though.
> >
> > I don't see any particular need to flatten it as such. Again, you're
> > trying to map "files" onto "array of bytes in a UNIX-like file system".
> > That's not the point.
> 
> Hard drives, CDs, floppies and tapes are flat. Hence to store it you're
> going to need to flatten it.

Since RAM is flat, I guess it's impossible to use non-flat structures at
all, right? Why is it OK to use "tangled" data structures in memory, but
not in a file?

For that matter, why are files contiguous arrays of bytes? Why do you
insist that the OS handle the directories but you handle what's inside
the files? Why do you insist that the OS handle allocation of space for
the files, but not handle allocation of space inside them? That's the
point I'm trying to get at.

Anyway, no, hard drives, CDs, and floppies all have sectors. So they're
arrays of sectors, each of which is an array of bytes.

And again, why do you want directories built in? Why not just flatten
them yourself?
 
> > There's a reason folks put names on files, on procedures, on users. The
> > same reason holds for individual pieces of data in a file. It's a win
> > whenever you store more than one piece of data in a file, like more than
> > one line in a text file, more than one user in a password file, etc. And
> > if you're only storing one atomic piece of data in a file, it's because
> > you're using the file's name as an index anyway. Have you never written
> > a program where the name of a file is calculated by the program?
> > "Image01.jpg", "Image02.jpg", ...?
> 
> And how much of a win is storing that in one file over storing it in
> a directory and tarring / zipping it for transport?

Significant. My point is that you *do* use such things, you just don't
recognise it. You say "I don't need complex intra-file data, because I
can make complex inter-file data instead." You're kind of perverting the
directories to serve as keys in exactly the same way that whatshisname
complains that people perverted file names to include the data type.

If you haven't used more sophisticated file systems, you don't see what
you're missing, just like if you've never used directories or relational
databases or OO databases or strong typing, you might have a hard time
seeing the value of it.

Why is strong typing good in a programming language and bad in
persistant data?

> >> > The type for an "Active Server Page" with Ada code embedded in
> >> > HTML markup under control of CVS?
> >>
> >> text/x-asp.
> >
> > And how does CVS know it can handle this,
> 
> text/*
> > and how does the web browser
> > know it needs to invoke the Ada compiler and not the Java compiler when
> > rebuilkding this page?
> 
> I would assume it reads the start of the file.

OK, so you're only solving half the problem here. The content-type on
the file isn't sufficient to figure out what you can do with the file
without reading the data. Why bother with it at all?

Why is strong typing good in a program and bad in a file?
 
> > The point is that no passive tagging system is going to be complete
> > enough that you can specify everything you need to know about the
> > program in the type tag.
> 
> Sure. And?

And why bother? What's the benefit of putting big complex heirarchical
types on files that are neither sufficient nor enforced? What keeps me
from writing a JPEG image into an Ada source file? If I can do that, why
do I need the file type?
 
> I've used Ada. Every so often in Ada, you're juggling twenty different
> types and having to constantly convert between them.

<sarcasm> Oh no. I've never had to juggle file types in a flat-file OS
either. Never had a problem with the wrong character set or line ending
translation, never had to convert from one image format to another, and
never had to change a file extension so some other program would accept
a text file and display it as HTML markup, and of course I've never
opened an image file with a text editor. </sarcasm>

> I fail to see the
> advantage to that in an OS. I don't want each program having its own
> set of types that are incompatible with everything else. I also want
> my editor to work any appropriate file, be it C, Ada, HTML, Tex,
> a diary, whatever.

Welcome to the wonderful world of object-oriented OSes. :-) As long as
the file type supports getting and setting lines of text, your editor
shouldn't have a problem with it. As long as it supports serialization
at all, your binary editor shouldn't have a problem with it.

Why wouldn't you want your editor to work with inappropriate file types?

> You ask how the web browser knows it needs to invoke the Ada compiler
> in my situation. How does the web browser know anything about the
> file in your situation?

The same way the web browser knows the types of the windows and buttons
it displays. It does a "with File.Text.Html" and then uses the routines
therein.

> How does this type get created? 

The same way any other type gets created. You write a package for it.

> What happens
> if you change it from Ada to Chill?

Then you have to figure out how to serialize it or figure out how to
translate it without serializing it. Always coding every single program
to the worst-case conditions is going to lead to all kinds of problems.
What if the next HTML standard specifies that all HTML tags should be in
Hebrew? What happens if the next version of emacs uses FORTH for its
scripting language instead of elisp?

> How does the editor know what type
> to create?

You tell it. Same as now.

> > Errr... When talking about designing and writing an OS, saying "oh,
> > don't worry, the device drivers will take care of it" doesn't work.
> 
> Sure it does. It's called stratifaction. When talking about user mode
> utilities, we can hand certain things off to the kernel, and let
> the kernel worry about it.

But to do that, you have to come up with some universal semantics for
the file system, which is what we're talking about.

If your files have keyed records, your copy program copies keys and
records. If your files have arrays of bytes, your copy program copies
arrays of bytes. The complexity of the file system doesn't preclude
writing universal utilities.
 
> > Why
> > not let the real data be the one with the pointers and strong types and
> > such, and only use streams when you want to communicate with a different
> > OS?
> 
> Because a plain text file is readable by 4 million different programs.
> Because the format for PNG is set in stone and readable by 40,000 different
> programs. 

Well, why don't you read what I said? Of course, the serialized data
formats are readable by any number of programs. That's why it's
important for programs that have data they want to port elsewhere to
serialize them. 

However, if the *only* way to store the data is to serialize it, then
every program has to go throught the overhead of parsing the data.

Look at it this way. To deal with GIF, you use a library. To deal with
PNG, you use a library. To deal with XML, you use a library. This
library's job is to convert from one serialized format (the GIF or PNG
or XML file) to another serialized format (stored in the swap space). It
also converts back again. If you're going to have that internal format
anyway, why not allow it to get stored directly? If it's the
representation of a type that has a defined external serialization, you
write a "serialize" and "deserialize" routine for that type. But guess
what? You have to do that *anyway* in your model.

In addition, this library you use for GIF, why not make *that* the
content-type of the file, rather than some arbitrary string? Why not say
"this file is a GIF because the interface to it is libgif.so"? Or "this
file is a GIF because the interface to it is with File.Image.GIF"?
That's what I'm suggesting, in essence. Of course, once you do that,
files start acting more like persistant variables than they do arrays of
bytes.

Indeed, you don't *really* have arrays of bytes in a UNIX-like OS. You
have calls like "read" and "write" that transfer *something* from a file
into your buffers. The buffers are arrays of characters, but the files
aren't. The OS does the serialization for you there too. Surely writing
to /dev/audio isn't transfering an array of bytes anywhere. Writing to a
fragmented file isn't transfering an array of bytes - the OS is dealing
with disk blocks and channel programs and stuff like that.

Think about the Windows Registry. The number of times you actually want
to turn that into a text file is minute compared to the number of times
you want to access it as a structured data store. The registry is not
defined in terms of the bytes that are in the file. It's defined in
terms of the interfaces to it. This is a *far* superior way of working
things, upward-compatibility-wise and ease-of-use wise. (Witness the
fact that Win3.1 "INI file" interfaces still work with Windows, but
Emacs can't keep its internal formats working. :-)

> However, the internal format for Emacs has been known to change
> between versions. It's hard to keep internal structures the same; much
> easier to conform to a consistent external standard.

Errr, and the point is? Perhaps that emacs internal formats, not
intending to be ported, don't need to be serialized except for the
primitive nature of the data the OS is willing to handle? And that
therefore when you upgrade emacs, you have to recompile the scripts the
first time you use them, in return for having far better performance for
the other 99.44% of the time you're not upgrading emacs?

> Also, I've worked with programs that used a database and those that use
> plain text files, and the latter seem more reliable. 

Sure thing. Tell this to the folks running the airline reservation
programs.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[David Starner]

On Wed, 29 Aug 2001 16:42:55 GMT, Darren New <dnew@san.rr.com> wrote:
> Why is strong typing good in a programming language and bad in
> persistant data?

Because I don't usually end up trying to debug persistant data
several months later, searching for one small minor bug.
 
> OK, so you're only solving half the problem here. The content-type on
> the file isn't sufficient to figure out what you can do with the file
> without reading the data. Why bother with it at all?

Most problems are unsolvable in the general form. It's basically an
extension of the Halting problem. We can't completely optimize code,
but we can try our best.
 
>> What happens
>> if you change it from Ada to Chill?
> 
> Then you have to figure out how to serialize it or figure out how to
> translate it without serializing it. Always coding every single program
> to the worst-case conditions is going to lead to all kinds of problems.

Is changing the language on a project really that rare? Deciding you
can't do it in JavaScript, and go with Java or Ada? Find that you
need to support Linux, so you change in from VBScript to JavaScript?

>> How does the editor know what type
>> to create?
> 
> You tell it. Same as now.

So you can create new types on the fly?
 
>> However, the internal format for Emacs has been known to change
>> between versions. It's hard to keep internal structures the same; much
>> easier to conform to a consistent external standard.
> 
> Errr, and the point is? 

The point is that if you dump the internal structures for version a,
and try to load it with version b, it won't work. If you save a file
as ISO-8859-1 plain text, and try to load with a different version,
it will, even if b is a lot earlier than a.

>> Also, I've worked with programs that used a database and those that use
>> plain text files, and the latter seem more reliable. 
> 
> Sure thing. Tell this to the folks running the airline reservation
> programs.

Why do I care about the airline reservation programs? Maybe if I was
dealing with the volume and amount of data they do, and I had the money 
to shell out for a decent database and the people to keep it working,
I might.

This has been a lot less productive than it could have been. I have been
reading what you've been writing. This just happens to be so far out of
my experiance that I'm not getting what you're saying. Part of the
problem is I've been falling into an argumentative mode; but it would
have been real helpful if you explained things up front - gave a
definition of file from the start, for example, or maybe some
references, web or book.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Darren New]

David Starner wrote:
> On Wed, 29 Aug 2001 16:42:55 GMT, Darren New <dnew@san.rr.com> wrote:
> > Why is strong typing good in a programming language and bad in
> > persistant data?
> 
> Because I don't usually end up trying to debug persistant data
> several months later, searching for one small minor bug.

But you debug the programs that generate it. I'd guess half of
accounting involved debugging persistant data. :-)

> > OK, so you're only solving half the problem here. The content-type on
> > the file isn't sufficient to figure out what you can do with the file
> > without reading the data. Why bother with it at all?
> 
> Most problems are unsolvable in the general form. It's basically an
> extension of the Halting problem. We can't completely optimize code,
> but we can try our best.

But that answer doesn't address the question. Why bother with data
typing that's insufficient to tell you how to work with the data? What's
the benefit of tagging data as COBOL source or Postscript at the file
system level if you can look at the data in the file and get a more
robust answer?

> >> What happens
> >> if you change it from Ada to Chill?
> >
> > Then you have to figure out how to serialize it or figure out how to
> > translate it without serializing it. Always coding every single program
> > to the worst-case conditions is going to lead to all kinds of problems.
> 
> Is changing the language on a project really that rare? Deciding you
> can't do it in JavaScript, and go with Java or Ada? Find that you
> need to support Linux, so you change in from VBScript to JavaScript?

Firstly, there's two assumptions I'm making. One, that a new OS written
in Ada would use Ada as its primary programming language, taking full
advantage of everything Ada has to offer. There's not a whole lot of
point that I can see in building, as a hobby, an AdaOS that compiles and
runs POSIX C programs right off the bat. Naturally, if you want to stay
compatible with all the assumptions that a C program written for UNIX
makes, you're going to wind up reinventing UNIX, and why bother with
that?

Secondly, I'm assuming that it's OK (because of the first assumption) to
change fundamental conceptual organizations. For example, it is possible
in the OS I'm thinking about to run a program indefinitely. Note, not
until you turn the power off. Not until you upgrade the OS code. Not
until you buy a new computer. Indefinitely. Forever. As long as you want
to keep porting the OS. Given this assumption, why bother serializing
your data every time you use it? If an image "file" was represented as a
collection of routines to get the width, height, and pixel data from an
image, why would you even care what the internal structure is?
Especially if there was also a function you could call that says "give
me back a JPEG (JFIF) stream representing the image" *and* a routine
that says "give me back a GIF stream representing the image"?

> >> How does the editor know what type
> >> to create?
> >
> > You tell it. Same as now.
> 
> So you can create new types on the fly?

Sure. That's kind of inherent in any file system, yes? I'm pretty sure I
can store Ada-95 sources on a FAT12 file system. How does *your* editor
know whether you're working with an Ada-95 source file or a COBOL source
file? You tell it, or you tell it how to distinguish between the two
based on contents or file name.
 
> >> However, the internal format for Emacs has been known to change
> >> between versions. It's hard to keep internal structures the same; much
> >> easier to conform to a consistent external standard.
> >
> > Errr, and the point is?
> 
> The point is that if you dump the internal structures for version a,
> and try to load it with version b, it won't work.

See assumption 2 above. You don't "dump" internal structures. 

> If you save a file
> as ISO-8859-1 plain text, and try to load with a different version,
> it will, even if b is a lot earlier than a.

Err, no, not really. If you save a Ada95 program in ISO-8859-1 and try
to compile it with an Ada83 compiler, it's not going to properly
recreate the internal structures.

You may be so used to serializing data and making sure you get *that*
part very correct that you don't realize just how much everyday effort
goes into such. Think about (say) your mail client. How much effort goes
into it parsing the MIME messages every single time you look at it? Of
course, if you want to switch to another mail client, you pick "export
mailbox as MH-format" or some such, then suck it into another client.
But how often do you really do this?

> >> Also, I've worked with programs that used a database and those that use
> >> plain text files, and the latter seem more reliable.
> >
> > Sure thing. Tell this to the folks running the airline reservation
> > programs.
> 
> Why do I care about the airline reservation programs? Maybe if I was
> dealing with the volume and amount of data they do, and I had the money
> to shell out for a decent database and the people to keep it working,
> I might.

My point was that saying a text-format database is more robust than a
more sophisticated database is kind of pointless. It's certainly not
more robust when you have the needs of a customer something like the
airline reservation industry. I'm honestly not sure what your point was
in talking about the database stuff to start with. I'm not saying you
should serialize binary data with the OS. I'm saying you shouldn't need
to serialize things at all. 

In other words, why should a file be an array of stream elements? Why
shouldn't the concept of "file" be an instantiation of a generic
shared_passive library unit?

> This has been a lot less productive than it could have been. I have been
> reading what you've been writing. This just happens to be so far out of
> my experiance that I'm not getting what you're saying.

My apologies. It takes a number of examples to see where the benefits
can be. I'm not even sure that EROS is the best example. Another good
example is Hermes, as described in "Hermes, a Language for Distributed
Computing." (Which is unfortunately out of print.)

> Part of the
> problem is I've been falling into an argumentative mode; but it would
> have been real helpful if you explained things up front - gave a
> definition of file from the start, for example, or maybe some
> references, web or book.

The reference to the EROS project earlier in the thread is a good place
to start thinking about this.
http://www.eros-os.org/essays/capintro.html
For example, in EROS, files don't have names. You get a (weak) pointer
to a file when you create it. You give that pointer to whoever else you
want to have that file. Since your program never has to exit, you never
have to worry about losing the pointer.

I thought I'd given some decent examples of other ways to make files,
such as
> Imagine an OS where "files" are actually protected objects, fully typed,
> that outlive your program's execution. Directories are simply persistant
> protected objects that act as arrays mapping strings to these "files".

The idea was that you would declare a library as pragma shared_passive,
and you could access the data structures managed by that library when
you started up your program (or a different program) again. 

I thought I had also mentioned the idea of a persistant storage_pool,
whereby you could name a storage pool, allocate things in it, exit,
start a different program naming the same storage pool, and access the
things previously allocated.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[Darren New]

> > Part of the
> > problem is I've been falling into an argumentative mode; but it would
> > have been real helpful if you explained things up front - gave a
> > definition of file from the start, for example, or maybe some
> > references, web or book.

Here's another example to think about. UNIX already has (at least) two
kinds of files: "plain" files and "directory" files. The calls on
"plain" files are read, write, and stat. The calls on "directory" files
are creat, unlink, stat, and readdir. Nobody complains they can't read
directories as streams. tar doesn't treat the two kinds of files the
same way. cp can't even deal with directory files. Many people seem to
miss the forest for the trees, thinking that all files in UNIX are
arrays of bytes.

I'm suggesting that when you *really* have a file that has an internal
structure, it can be appropriate to manage it with calls other than ones
that map it to an array of bytes.

SQL database files aren't arrays of bytes. You manage them with quite
sophisticated calls. Sure, you can back up the database (perhaps) onto a
serialized format, but I don't think anyone would say that the dump of
the SQL tables onto a tape are "an SQL database".

If you're building an AdaOS, why not make files that are managed with
Ada semantics?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[M. A. Alves]

> If you're building an AdaOS, why not make files that are managed with
> Ada semantics?

My view is close to that.  ADTs.  File = persistent (un)bounded array of
storage element (plus user and permission information).  Dir = persistent
(un)bounded array of files (plus ditto).

But in my dream OS directories would be just one of many ways of grouping
files.  Other ways: by owner, permission, create time, last update time,
format...  And a file could really belong to more than one
directory-category.  An actual forest, which UNIX file system is not (it
is a tree).

Ultimately it is an identity problem.  UNIX file has key path/filename, so
directories must form a tree (not a forest).  Dream OS file would have
another key scheme, perhaps OID (Object Identifier) (= UNIX inode?).

Just my 2 cents.

Thanks.

--
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Progress on AdaOS

[Darren New]

"M. A. Alves" wrote:
> 
> > If you're building an AdaOS, why not make files that are managed with
> > Ada semantics?
> 
> My view is close to that.  ADTs.  File = persistent (un)bounded array of
> storage element (plus user and permission information).  Dir = persistent
> (un)bounded array of files (plus ditto).

But why limit a file to an array of storage elements? Why not persistant
unbounded storage pool? Or persistant unbounded tagged classwide type?
Or persistant protected object? (Ada already has the concept of a
persistant storage mechanism, pragma shared_passive. Why not use that?)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[M. A. Alves]

> > > If you're building an AdaOS, why not make files that are managed with
> > > Ada semantics?
> >
> > My view is close to that.  ADTs.  File = persistent (un)bounded array of
> > storage element (plus user and permission information).  Dir = persistent
> > (un)bounded array of files (plus ditto).
>
> But why limit a file to an array of storage elements? Why not persistant
> unbounded storage pool? Or persistant unbounded tagged classwide type?
> Or persistant protected object?
> . . .

Hmmm...  Different levels, I guess.  I think a _kernel_ should deal with
storage elements alone.  Higher levels (e.g. a file of integers) would be
an elaboration upon that.  Not the OS role.

Basically yours is the radical OO view = high hierachies vs. a kind of
bottom-up approach to OS development = microkernel.  I tend to favour the
latter, but perhaps a blend is possible.  Hmmm...

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Progress on AdaOS

[Ted Dennison]

In article <mailman.999282639.28910.comp.lang.ada@ada.eu.org>, M. A. Alves
says...
>Basically yours is the radical OO view = high hierachies vs. a kind of
>bottom-up approach to OS development = microkernel.  I tend to favour the
>latter, but perhaps a blend is possible.  Hmmm...

That depends on your definition of "radical". The Amiga was used as an example
for some of these concepts. It was very successful in its day. Its OS was
entirely OO, and it was initially written back in the early 80's. 

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

Re: Progress on AdaOS

[Darren New]

"M. A. Alves" wrote:
> 
> > > > If you're building an AdaOS, why not make files that are managed with
> > > > Ada semantics?
> > >
> > > My view is close to that.  ADTs.  File = persistent (un)bounded array of
> > > storage element (plus user and permission information).  Dir = persistent
> > > (un)bounded array of files (plus ditto).
> >
> > But why limit a file to an array of storage elements? Why not persistant
> > unbounded storage pool? Or persistant unbounded tagged classwide type?
> > Or persistant protected object?
> > . . .
> 
> Hmmm...  Different levels, I guess.  I think a _kernel_ should deal with
> storage elements alone.  Higher levels (e.g. a file of integers) would be
> an elaboration upon that.  Not the OS role.

Making a strict separation like that is exactly the kind of thing that
causes mental impedence mismatch. It's the same kind of reasoning that
says "let the language deal with processes, and save threading for a
library." :-)

Of course, the kernel deals with storage elements, because that's all
there really is. That's why we have compilers, to distinguish pointers
from integers from floats. :-) 
It's a question of how the kernel presents those storage elements to a
program. For example, mmap() deals with storage elements *and* files,
and if you build a storage_pool that used mmap, you could (perhaps)
allocate stuff from the storage pool, then stop your process, start up a
different one, and use the complex data structures that are in that
storage pool.

On the other hand, FORTH really *does* use *only* storage elements. That
means no directories and no files. Your disk really is an array of
storage elements. Directories are the responsibility of your code. Is
that really what you want in a kernel?

It's not a question of "high level" vs "low level". It's just a question
of where you draw the boundary in a continuous series of levels. And
thinking that knowing that the "type" of the data in the file is
image/gif is vital, but being willing to read the file to find out of
it's GIF87 or GIF89 is OK too doesn't make sense to me. And saying "this
is an image file, and that fact cannot change without a change in the
data" and then letting programs copy the raw bytes is just silly too.

> Basically yours is the radical OO view = high hierachies vs. a kind of
> bottom-up approach to OS development = microkernel.  I tend to favour the
> latter, but perhaps a blend is possible.  Hmmm...

You can still do it as a microkernel. It's the programs defining the
format, not the kernel. The kernel just has to allow persistant storage
of something other than storage elements. In particular, the language
has to have a binding such that the fact that everything's really
storage elements at the bottom is hidden by the type system.

I think Ada is powerful enough to have such ideas integrated seemlessly.
I don't know why else you'd want to write an OS in Ada, other than as
practice with Ada and OSes.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[David Starner]

On Fri, 31 Aug 2001 20:00:07 GMT, Darren New <dnew@san.rr.com> wrote:
> Making a strict separation like that is exactly the kind of thing that
> causes mental impedence mismatch. It's the same kind of reasoning that
> says "let the language deal with processes, and save threading for a
> library." :-)

It's also the same kind of reasoning that says "let the language deal with
text, and save XML for a library." What should go into the OS or
language, and what should be supplied seperately is debated fiercely, but
something's are going to have to go out, and some in.

> On the other hand, FORTH really *does* use *only* storage elements. That
> means no directories and no files. Your disk really is an array of
> storage elements. Directories are the responsibility of your code. Is
> that really what you want in a kernel?

Not having directories in the kernel tends to mean that directories aren't
implemented in any coherant standard way. There are coherant standard ways
_that are followed consistently_ in how to store data to disk, without
it being in the kernel.
 
> And
> thinking that knowing that the "type" of the data in the file is
> image/gif is vital, but being willing to read the file to find out of
> it's GIF87 or GIF89 is OK too doesn't make sense to me. 

Because whether it's GIF87 or 89 is a mostly irrelevant fact, and there's
zero chance of confusing the two once you know it's a GIF file. Some thing
much more interesting is whether it's a picture of Robert Dewar or Tucker Taft,
but that's something no one's talked about putting in the type.

> I think Ada is powerful enough to have such ideas integrated seemlessly.

See, Modula-3 did have such ideas seemlessly implemented. Which raises
two points: one, it's evidence that there's no need to do it in the
kernel, that it can be done in the language or libraries without kernel
help. Second, where's Modula-3 today? (Last time I checked, with one
maintained compiler, which is a hack on an old version of gcc, and a
nearly dead newsgroup.) If this was so important why didn't it succeed,
or at least the ideas get put into languages that are used? ABC also
had persistant variables; but when Guido von Rossum made Python with
ABC in fond memory, he didn't include persistant variables.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[Darren New]

David Starner wrote:
> 
> On Fri, 31 Aug 2001 20:00:07 GMT, Darren New <dnew@san.rr.com> wrote:
> > Making a strict separation like that is exactly the kind of thing that
> > causes mental impedence mismatch. It's the same kind of reasoning that
> > says "let the language deal with processes, and save threading for a
> > library." :-)
> 
> It's also the same kind of reasoning that says "let the language deal with
> text, and save XML for a library." What should go into the OS or
> language, and what should be supplied seperately is debated fiercely, but
> something's are going to have to go out, and some in.

Right. As an aside, since XML is a serialization technique, I'd leave it
to the libraries implementing the data types.

Anyway, it *would* be libraries implementing the types of files. I'm
just suggesting that serialization isn't a necessary component of a
"file", any more than you need to explicitly load and store pages for
virtual memory in modern systems.

> > On the other hand, FORTH really *does* use *only* storage elements. That
> > means no directories and no files. Your disk really is an array of
> > storage elements. Directories are the responsibility of your code. Is
> > that really what you want in a kernel?
> 
> Not having directories in the kernel tends to mean that directories aren't
> implemented in any coherant standard way.

No more than a lack of image types in a kernel means that images aren't
implemented in a coherent standard ways. FORTH simply has library
routines to handle directories.

> There are coherant standard ways
> _that are followed consistently_ in how to store data to disk, without
> it being in the kernel.

I'm not sure what this is supposed to mean. 
 
> > And
> > thinking that knowing that the "type" of the data in the file is
> > image/gif is vital, but being willing to read the file to find out of
> > it's GIF87 or GIF89 is OK too doesn't make sense to me.
> 
> Because whether it's GIF87 or 89 is a mostly irrelevant fact, and there's
> zero chance of confusing the two once you know it's a GIF file. Some thing
> much more interesting is whether it's a picture of Robert Dewar or Tucker Taft,
> but that's something no one's talked about putting in the type.

Well, my basic point there was that if you're going to have "strongly
typed files", as suggested by the original web pages, then the ability
to treat an image file as raw bits is a bad thing. The suggestion is
that a files data type cannot change without a change in content, but
this is just wrong. Certainly I can change a file's type from raw text
to HTML on most modern systems (including the Mac) without changing the
content.
 
> > I think Ada is powerful enough to have such ideas integrated seemlessly.
> 
> See, Modula-3 did have such ideas seemlessly implemented. Which raises
> two points: one, it's evidence that there's no need to do it in the
> kernel, that it can be done in the language or libraries without kernel
> help.

Well, it depends on what ideas you mean, really.

> Second, where's Modula-3 today? (Last time I checked, with one
> maintained compiler, which is a hack on an old version of gcc, and a
> nearly dead newsgroup.) If this was so important why didn't it succeed,

I never said it was important. I simply said it might be a good idea to
think about it for an AdaOS. Personally, I don't know why someone would
think an AdaOS is important simply because it's written in Ada.

> or at least the ideas get put into languages that are used? ABC also
> had persistant variables; but when Guido von Rossum made Python with
> ABC in fond memory, he didn't include persistant variables.

I think that's generally because it's hard to do with modern operating
systems. But if you're rewriting the OS from scratch, why start with the
assumption "Nobody else has done this, so we shouldn't do it either."

Anyway, nuff said.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Ada OS talk (was: Progress on AdaOS)

[M. A. Alves]

> Anyway, it *would* be libraries implementing the types of files.

Yes.  That is what I meant with "different levels".  I still think you
need a storage element level as a building block for the file types and
other elaborations.  And this would be the role of the kernel.

> just suggesting that serialization isn't a necessary component of a
> "file", any more than you need to explicitly load and store pages for
> virtual memory in modern systems.

By serialization you mean a (do_first, do_next, end_error) sort of thing?
I think the best building block is the (un)bounded array of storage
elements, which is more than this.  But of course I may be wrong.

> > Not having directories in the kernel tends to mean that directories aren't
> > implemented in any coherant standard way.
>
> No more than a lack of image types in a kernel means that images aren't
> implemented in a coherent standard ways. FORTH simply has library
> routines to handle directories.

My point exactly.

> > Because whether it's GIF87 or 89 is a mostly irrelevant fact, and there's
> > zero chance of confusing the two once you know it's a GIF file. Some thing
> > much more interesting is whether it's a picture of Robert Dewar or Tucker Taft,
> > but that's something no one's talked about putting in the type.
>
> Well, my basic point there was that if you're going to have "strongly
> typed files", as suggested by the original web pages, then the ability
> to treat an image file as raw bits is a bad thing. The suggestion is
> that a files data type cannot change without a change in content, but
> this is just wrong. Certainly I can change a file's type from raw text
> to HTML on most modern systems (including the Mac) without changing the
> content.

This is all fine, but, again, not at all kernelian.

I am being extremely kernelist as a lesson learned (negatively) from AdaOS
history.  They did not concentrate on the kernel--and the project failed I
think because of this at least in part. The current discussion is
excelent, but is about things outside the kernel.  And to get a kernel
_done_ I think a it should be simple viz.  provide a simple structure viz.
the (un)bounded array of storage elements as a building block and then
when the thing is going we can implement directories, file types etc.

In short: give me a OS that only handles "raw bits" and I can build
everything upon that; furthermore, aim at such an OS and you will get it
done; aim at a full-featured-OS-language-like OS and you will not even get
it started.

--
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Ada OS talk (was: Progress on AdaOS)

[Darren New]

"M. A. Alves" wrote:
> 
> > Anyway, it *would* be libraries implementing the types of files.
> 
> Yes.  That is what I meant with "different levels".  I still think you
> need a storage element level as a building block for the file types and
> other elaborations.  And this would be the role of the kernel.

Right. The hardware is going to enforce this. But I don't want to reveal
a storage-element level as a building block for directories, for
example.

> > just suggesting that serialization isn't a necessary component of a
> > "file", any more than you need to explicitly load and store pages for
> > virtual memory in modern systems.
> 
> By serialization you mean a (do_first, do_next, end_error) sort of thing?

No, I mean flattening into something that has to be parsed. Serializing
a DOM tree involves creating XML. Serializing a directory tree is what
"tar" does. Nobody works with XML as a big text string. Everyone parses
it into some internal representation, works with the internal
representation, then pumps the XML back out. Nobody works with a
directory tree represented as a tar file. Everyone runs it thru untar,
gets the tree, then does operations on the files within. For example,
how would you make all the files in a tarball globally readable? Would
you (a) run thru the tar file fiddling bits in the headers, or would you
(b) untar it, use chmod -R, then tar it up again?

> I think the best building block is the (un)bounded array of storage
> elements, which is more than this.  But of course I may be wrong.

It's a good low-level building block, but it's not a good higher-level
building block. I think records are good. I think the ability to insert
and delete records is good. I think the ability to have at least one and
maybe many ordered indicies on records is good. 

> > No more than a lack of image types in a kernel means that images aren't
> > implemented in a coherent standard ways. FORTH simply has library
> > routines to handle directories.
> 
> My point exactly.

I'm lost. I don't think we're really talking about image types here.
We're talking about how you store something more complex than an array
of bytes. If your kernel only supports "array of bytes" as a data type,
then someone has to write code for every non-array-of-bytes to store it
in an array of bytes then pull it back in again. This is what streams
try to do, except that you have to deal with pointers and such yourself.
 
> This is all fine, but, again, not at all kernelian.

It depends. I'd expect mmap() is neither particularly more nor less
difficult to implement than read() and write(). That, plus the
appropriate libraries, should be close to enough, for the file system
I'm talking about.

Of course, having programs that don't die is even better.
 
> I am being extremely kernelist as a lesson learned (negatively) from AdaOS
> history.  They did not concentrate on the kernel--and the project failed I
> think because of this at least in part. The current discussion is
> excelent, but is about things outside the kernel.  And to get a kernel
> _done_ I think a it should be simple viz.  provide a simple structure viz.
> the (un)bounded array of storage elements as a building block and then
> when the thing is going we can implement directories, file types etc.

> In short: give me a OS that only handles "raw bits" and I can build
> everything upon that; furthermore, aim at such an OS and you will get it
> done; aim at a full-featured-OS-language-like OS and you will not even get
> it started.

I don't think it's a question of whether the kernel sees the files as
"raw bits" or not. It's a question of "what does a process look like"
and "how does a process access a file". If a process is something that
never needs to exit, and all access to files is done via something like
mmap(), then your kernel can dispense with "file system" altogether,
allocating the entire disk as one big swap file. I can't imagine it gets
much simpler than this. Then all you need to do to make things
convenient is to tweak the runtime to let you allocate specific storage
pools to specific areas of memory, etc.

Of course, the pointers in such a memory-mapped storage pool will *look*
like raw bits to the device reading and writing sectors of disk. The
point is that they'll still look like strongly-typed pointers to the Ada
program.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada OS talk (was: Progress on AdaOS)

[M. A. Alves]

> > > Anyway, it *would* be libraries implementing the types of files.
> >
> > Yes.  That is what I meant with "different levels".  I still think you
> > need a storage element level as a building block for the file types and
> > other elaborations.  And this would be the role of the kernel.
>
> Right. The hardware is going to enforce this. But I don't want to reveal
> a storage-element level as a building block for directories, for
> example.

You are thinking Unix again ;-)  Dont!  Down with directories!  That is
just a way of grouping files among many others, including file typing, and
so also built upon the storage-element level.

> > By serialization you mean a (do_first, do_next, end_error) sort of thing?
>
> No, I mean flattening into something that has to be parsed.
> . . .

OK.  Them it is definitely an outer layer (w.r.t. the kernel).

> > I think the best building block is the (un)bounded array of storage
> > elements, which is more than this.  But of course I may be wrong.
>
> It's a good low-level building block, but it's not a good higher-level
> building block. I think records are good. I think the ability to insert
> and delete records is good. I think the ability to have at least one and
> maybe many ordered indicies on records is good.

I meant the best _low_level_ building block.  Then a middle level layer
would provide records etc. but this edifice needs bricks.

> > > No more than a lack of image types in a kernel means that images aren't
> > > implemented in a coherent standard ways. FORTH simply has library
> > > routines to handle directories.
> >
> > My point exactly.
>
> I'm lost. I don't think we're really talking about image types here.
> . . .

The point was that _both_ directories and file types are similarly above
kernel level, without hindering coherency or performance.

Not important an issue really at this point.  Hmmm... what point?  I would
expect this talk would result in a sort of strategic plan for building an
OS as a hobby by Adaists.  To that effect I propose a generic principle of
simplicity/smallness.  That is why my messages have a general "downsizing"
tone.  Remember the fall of the AdaOS.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Any OS can treat the file system as a whole separate issue. Any Ada OS would
probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
well as maybe supporting its own thing. The point is, that discussion can be
stalled off until there is first a working Kernel capable of running a file
system.

Make the project too big and it will just crumble from its own weight. Take
the file system ideas and put them in a folder marked "To be argued about
after some level of success is achieved." I'd say the same things about
network support, etc., except in so far as a Kernel will need to leave the
door open to work in a networked environment. Beyond leaving the door open,
no other design decisions need to be made at this time.

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/


"M. A. Alves" <maa@liacc.up.pt> wrote in message
news:mailman.999544263.23337.comp.lang.ada@ada.eu.org...
>
> The point was that _both_ directories and file types are similarly above
> kernel level, without hindering coherency or performance.
>
> Not important an issue really at this point.  Hmmm... what point?  I would
> expect this talk would result in a sort of strategic plan for building an
> OS as a hobby by Adaists.  To that effect I propose a generic principle of
> simplicity/smallness.  That is why my messages have a general "downsizing"
> tone.  Remember the fall of the AdaOS.
>

Re: Ada OS talk (was: Progress on AdaOS)

[Gary Scott]

A look at OS/2's recent file system(s) changes would be in order.  It
supports treating multiple hard drives as a single large drive,
transparently, easy to set up and use.

Marin David Condic wrote:
> 
> Any OS can treat the file system as a whole separate issue. Any Ada OS would
> probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
> well as maybe supporting its own thing. The point is, that discussion can be
> stalled off until there is first a working Kernel capable of running a file
> system.
> 
> Make the project too big and it will just crumble from its own weight. Take
> the file system ideas and put them in a folder marked "To be argued about
> after some level of success is achieved." I'd say the same things about
> network support, etc., except in so far as a Kernel will need to leave the
> door open to work in a networked environment. Beyond leaving the door open,
> no other design decisions need to be made at this time.
> 
> 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/
> 
> "M. A. Alves" <maa@liacc.up.pt> wrote in message
> news:mailman.999544263.23337.comp.lang.ada@ada.eu.org...
> >
> > The point was that _both_ directories and file types are similarly above
> > kernel level, without hindering coherency or performance.
> >
> > Not important an issue really at this point.  Hmmm... what point?  I would
> > expect this talk would result in a sort of strategic plan for building an
> > OS as a hobby by Adaists.  To that effect I propose a generic principle of
> > simplicity/smallness.  That is why my messages have a general "downsizing"
> > tone.  Remember the fall of the AdaOS.
> >

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

I don't know if DEC invented it or implemented it first or anything like
that, but the first time I saw that was with VMS. They had "disk striping"
which let you spread files or a database across several drives for faster
access and/or redundancy. Not really that new since a disk with multiple
independent heads is essentially the same problem & I think those were in
existence a long time ago. Its a useful technique.

I'd consider that to be outside of the "file system" as an "implementation
detail" peculiar to a specific kind of device. A RAID or JABOD would be just
one storage medium among many. (Should a file system support paper tape,
punch cards and similar devices?)

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/


"Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
news:3B94E65B.CDA2CAB7@lmtas.lmco.com...
> A look at OS/2's recent file system(s) changes would be in order.  It
> supports treating multiple hard drives as a single large drive,
> transparently, easy to set up and use.
>

Re: Ada OS talk (was: Progress on AdaOS)

[Gary Scott]

I thought VM and MVS had this long before DEC.

Marin David Condic wrote:
> 
> I don't know if DEC invented it or implemented it first or anything like
> that, but the first time I saw that was with VMS. They had "disk striping"
> which let you spread files or a database across several drives for faster
> access and/or redundancy. Not really that new since a disk with multiple
> independent heads is essentially the same problem & I think those were in
> existence a long time ago. Its a useful technique.
> 
> I'd consider that to be outside of the "file system" as an "implementation
> detail" peculiar to a specific kind of device. A RAID or JABOD would be just
> one storage medium among many. (Should a file system support paper tape,
> punch cards and similar devices?)
> 
> 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/
> 
> "Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
> news:3B94E65B.CDA2CAB7@lmtas.lmco.com...
> > A look at OS/2's recent file system(s) changes would be in order.  It
> > supports treating multiple hard drives as a single large drive,
> > transparently, easy to set up and use.
> >

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Could be. Like I said, it was just in VMS that I first saw it in a
production setting. The concept has got to go back to the invention of the
disk drive since it is basically just an optimization technique for picking
the next track to read/write.

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/


"Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
news:3B9540ED.7EF3C7B5@lmtas.lmco.com...
> I thought VM and MVS had this long before DEC.
>
> Marin David Condic wrote:
> >
> > I don't know if DEC invented it or implemented it first or anything like
> > that, but the first time I saw that was with VMS. They had "disk
striping"
> > which let you spread files or a database across several drives for
faster

Re: Ada OS talk (was: Progress on AdaOS)

[Darren New]

> Any OS can treat the file system as a whole separate issue.

Not really. My point was that it's possible to create an OS where the
concept of "file system" doesn't even exist. I'm not sure what your
"kernel" is going to do other than process scheduling and I/O. What did
you have in mind?

Take a look, for example, at the EROS operating system. It's a bit
radical, but there aren't really "files" as such in it, in the sense
that the entire disk is one giant swap file and files are simply
variables held by processes. You do IPC to a process that has access to
the data you want in order to get it. The data isn't just "there"
without a process to access it for you.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Well, I don't know what you want to call an "Operating System" but there are
plenty of real time OS's that never deal with the concept of a "File"
because the hardware has no use for it. An OS can have a means of
bootstrapping itself into some flavor of memory and start executing without
there being a "File System" in any conventional sense. Hence I believe that
its possible to deal with lower-level execution issues & get something
capable of running a program and save any file system issues for a later
date. (Oh, you'd probably have to dummy some things up since typically a
program has got to reside *somewhere* - but if the OS has some rudimentary
monitor built into it to enable program loading from some collection of
sources, you could build something that worked, without having to deal with
a file system.)

I understand the notion of having no visible file system in the traditional
sense. "Disk" is just seen as a kind of extension to "Memory". I have no
objection to that sort of design - except possibly that it makes you
incompatible to some extent with the rest of the universe and may have some
limitations. (How are you going to get at Unix or Windows files on a network
if there is no visible file system - or some extension thereof? Ada has
facilities for handling "files" so there ought to be some kind of support
for that. Does it need to be "traditional"? Not necessarily - but it ought
to allow for the fact that you'll want to look at stuff that isn't built
under your own home-grown system.)

I kind of like a generalization that says "all that exists is 'storage' so
don't distinguish between an array in memory and a file on disk". However,
any practical OS is going to have to deal with the need to get real specific
about devices & hardware at points in time. For embedded things, this is
obvious: "I need this particular EEPROM or that specific I/O port..." But
even in general purpose computers, programmers will find a need to insist
that data reside in specific physical devices. As long as you can get there
from here, I'm happy.

One of the better ideas I've heard was to base any file system on URLs so
that the interface to the software is the same no matter what kind of data
or where it resides. That works nicely in conjunction with XML as the means
for handling any GUI development. However, I'm still convinced that those
sorts of issues can and should be stalled off until some small level of
working OS is actually built and running.

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/


"Darren New" <dnew@san.rr.com> wrote in message
news:3B950BAD.B23ECB43@san.rr.com...
> > Any OS can treat the file system as a whole separate issue.
>
> Not really. My point was that it's possible to create an OS where the
> concept of "file system" doesn't even exist. I'm not sure what your
> "kernel" is going to do other than process scheduling and I/O. What did
> you have in mind?
>
> Take a look, for example, at the EROS operating system. It's a bit
> radical, but there aren't really "files" as such in it, in the sense
> that the entire disk is one giant swap file and files are simply
> variables held by processes. You do IPC to a process that has access to
> the data you want in order to get it. The data isn't just "there"
> without a process to access it for you.
>
> --
> Darren New
> San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada OS talk (was: Progress on AdaOS)

[Ole-Hjalmar Kristensen]

Darren New <dnew@san.rr.com> writes:

> > Any OS can treat the file system as a whole separate issue.
> 
> Not really. My point was that it's possible to create an OS where the
> concept of "file system" doesn't even exist. I'm not sure what your
> "kernel" is going to do other than process scheduling and I/O. What did
> you have in mind?
> 
> Take a look, for example, at the EROS operating system. It's a bit
> radical, but there aren't really "files" as such in it, in the sense
> that the entire disk is one giant swap file and files are simply
> variables held by processes. You do IPC to a process that has access to
> the data you want in order to get it. The data isn't just "there"
> without a process to access it for you.
> 
> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.

Radical, yes, but not new. IBM has done that for ages.

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: Ada OS talk (was: Progress on AdaOS)

[David Starner]

On Tue, 4 Sep 2001 09:02:04 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> Any OS can treat the file system as a whole separate issue. Any Ada OS would
> probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
> well as maybe supporting its own thing. The point is, that discussion can be
> stalled off until there is first a working Kernel capable of running a file
> system.

But you don't want to fall into the trap of ignoring the file system.
File systems are key part of an style - a FAT style fs, a VFAT style
fs, a NTFS style fs, a Unix style fs, a Mac OS fs - all made their
mark on their systems, with permissions, valid file names and structure.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Ada OS talk (was: Progress on AdaOS)

[Brian Catlin]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9n3h11$9ic1@news.cis.okstate.edu...
> On Tue, 4 Sep 2001 09:02:04 -0400, Marin David Condic
<dont.bother.mcondic.auntie.spam@[> wrote:
> > Any OS can treat the file system as a whole separate issue. Any Ada OS would
> > probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
> > well as maybe supporting its own thing. The point is, that discussion can be
> > stalled off until there is first a working Kernel capable of running a file
> > system.
>
> But you don't want to fall into the trap of ignoring the file system.
> File systems are key part of an style - a FAT style fs, a VFAT style
> fs, a NTFS style fs, a Unix style fs, a Mac OS fs - all made their
> mark on their systems, with permissions, valid file names and structure.

Right, and this is one of the big traps the Microsoft fell into with NT; they
didn't have routines for validating file specifications, permissions, etc. on a
per-file system basis.  Initially, NTFS supported lots of cool features,
including multiple versions of a file (just like VMS), but the Win32 API (which
is arguably one of the worlds ugliest) didn't understand file systems other than
FAT, so many of the cool features of NTFS were inaccessible and eventually
dropped.

 -Brian

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

I certainly wouldn't want to ignore the file system. What I'm suggesting is
that you could get a useful piece of an OS built without designing the file
system initially. To the extent that a Boot-Loader/Kernel/Core would need to
load programs to run, you'd have to connect to a file system of some sort,
but you could hide that beneath a package spec & just simulate it with some
existing file system. The point being that doing so you'd have something to
show & work with rather than creating so many requirements & raising so many
debates that nothing ever gets done. Better to have some simple piece of the
plan up and working and save the file system issues for later.

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" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9n3h11$9ic1@news.cis.okstate.edu...
>
> But you don't want to fall into the trap of ignoring the file system.
> File systems are key part of an style - a FAT style fs, a VFAT style
> fs, a NTFS style fs, a Unix style fs, a Mac OS fs - all made their
> mark on their systems, with permissions, valid file names and structure.
>

Re: Ada OS talk (was: Progress on AdaOS)

[David Starner]

On Thu, 6 Sep 2001 09:59:11 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> I certainly wouldn't want to ignore the file system. What I'm suggesting is
> that you could get a useful piece of an OS built without designing the file
> system initially. To the extent that a Boot-Loader/Kernel/Core would need to
> load programs to run, you'd have to connect to a file system of some sort,
> but you could hide that beneath a package spec & just simulate it with some
> existing file system. 

Why would writing the code for some existing file system and the code to
make that system look like you want be any easier then writing some
simple file system that actually fits what you're trying to do? 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Well, think about it for a minute. If the initial objective is simply to get
something up and running and you've gone to the effort of building some
micro kernel & scheduler, then about all you need (initially) is some
ability to cause a program to be loaded from some source. You have not even
really got to the point where you have developed any serious device
drivers - just got code cycling in a box - so you're not concerned with
being able to run a sophisticated database app or anything like that yet.
You could dummy-up just enough of a file loader (hiden behind a package
spec) so that down the road, if you build your own file system (or interface
to NTFS, Unix, VMS, or anything else for that matter) you aren't in some
sort of major revision mode on your little core OS.

To design and build a full-blown file system is a *big* job. Just look at
everything that is in NTFS. Not to mention the fact that as is obvious here,
there are dozens of competing and incompatible strategies for designing one.
If you set as an objective getting a file system in place before releasing
anything, I admire the ambition, but I think it would cause the project to
languish. Obviously, you can go off and build anything you please and I'd be
the last one on the planet to try to stop you. I just think that it is too
ambitious for a first cut.

My idea for "Phase One"  would be to build just enough of an OS to be able
to boot it from a floppy & have a scheduler capable of loading some
pure-machine-code programs and have those programs up and cycling. You need
that much at minimum in order to accomplish anything else. You get the added
advantage that this much of an OS could be useful in embedded applications
where you have no file system, etc. Having a piece that big allows you to
hammer out the kernel and scheduling to get something that would make a
solid base for everything else.

But if you want to go write a file system - go right ahead.

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" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9n8o51$aik1@news.cis.okstate.edu...
>
> Why would writing the code for some existing file system and the code to
> make that system look like you want be any easier then writing some
> simple file system that actually fits what you're trying to do?
>

Re: Ada OS talk (was: Progress on AdaOS)

[Michael Garrett]

OAR had an Ada version of the RTEMS operating system a while back. I think
they have dropped support
for it, but I'm sure the source is available from them. This would probably
be a good starting point.

Michael C. Garrett



Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9nala6$p3$1@nh.pace.co.uk...
> Well, think about it for a minute. If the initial objective is simply to
get
> something up and running and you've gone to the effort of building some
> micro kernel & scheduler, then about all you need (initially) is some
> ability to cause a program to be loaded from some source. You have not
even
> really got to the point where you have developed any serious device
> drivers - just got code cycling in a box - so you're not concerned with
> being able to run a sophisticated database app or anything like that yet.
> You could dummy-up just enough of a file loader (hiden behind a package
> spec) so that down the road, if you build your own file system (or
interface
> to NTFS, Unix, VMS, or anything else for that matter) you aren't in some
> sort of major revision mode on your little core OS.
>
> To design and build a full-blown file system is a *big* job. Just look at
> everything that is in NTFS. Not to mention the fact that as is obvious
here,
> there are dozens of competing and incompatible strategies for designing
one.
> If you set as an objective getting a file system in place before releasing
> anything, I admire the ambition, but I think it would cause the project to
> languish. Obviously, you can go off and build anything you please and I'd
be
> the last one on the planet to try to stop you. I just think that it is too
> ambitious for a first cut.
>
> My idea for "Phase One"  would be to build just enough of an OS to be able
> to boot it from a floppy & have a scheduler capable of loading some
> pure-machine-code programs and have those programs up and cycling. You
need
> that much at minimum in order to accomplish anything else. You get the
added
> advantage that this much of an OS could be useful in embedded applications
> where you have no file system, etc. Having a piece that big allows you to
> hammer out the kernel and scheduling to get something that would make a
> solid base for everything else.
>
> But if you want to go write a file system - go right ahead.
>
> 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" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
> news:9n8o51$aik1@news.cis.okstate.edu...
> >
> > Why would writing the code for some existing file system and the code to
> > make that system look like you want be any easier then writing some
> > simple file system that actually fits what you're trying to do?
> >
>
>
>

RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS)

[Simon Clubley]

On Sun, 9 Sep 2001 22:20:33 -0500, in article
<9nhbjd$dcg$1@suaar1aa.prod.compuserve.com>, Michael Garrett wrote:
>
>OAR had an Ada version of the RTEMS operating system a while back. I think
>they have dropped support
>for it, but I'm sure the source is available from them. This would probably
>be a good starting point.
>
>Michael C. Garrett

The situation's a bit more complicated than that. :-)

OARcorp _do_ support Ada as a development environment for RTEMS. However,
some of the BSP's (for example, the i386 BSP) have moved from COFF to ELF.

The current GCC used for GNAT, 2.8.x, generates COFF format binaries. It has
been commented on several times in the RTEMS mailing list that OARcorp are
eagerly awaiting for ACT to deliver a GNAT for GCC 3.x. :-)

Simon.

PS: I am not associated with OARcorp in any way apart from wanting to use
Ada with RTEMS...

-- 
Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFP
In the task of removing Microsoft from the marketplace, I have discovered a
truly remarkable plan, but this signature is too small to contain it.

Re: RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS)

[Stephen Leake]

Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:

> <snip> 
> The situation's a bit more complicated than that. :-)
> 
> OARcorp _do_ support Ada as a development environment for RTEMS. However,
> some of the BSP's (for example, the i386 BSP) have moved from COFF to ELF.

Hmm. In my experience, a Board Support Package (BSP) is written in C,
or Ada, or (most likely) Assembler. _not_ object code. 

So what does it mean that a BSP has "moved from COFF to ELF"? 

Maybe the BSP defines the loader, and it needs to know the object file
format. I guess that would make sense.

> The current GCC used for GNAT, 2.8.x, generates COFF format
> binaries. 

This is misleading. GCC, the compiler, does not generate binaries; it
generates Assembler code. The system assembler and linker generate
binaries. If using the Gnu assembler and linker, they come from the
binutils package, not the gcc package. So just because GNAT uses gcc
2.8.1, does not mean RTEMS can't use it with binutils 2.11 (latest on
Gnu site).

I suppose there may be some upward incompatibilities, but I'd be
surprised.

> It has been commented on several times in the RTEMS mailing list
> that OARcorp are eagerly awaiting for ACT to deliver a GNAT for GCC
> 3.x. :-)

They don't have to use only the binary distributions from ACT! I would
consider it part of a 3rd parties job, to repackage things for exactly
this kind of reason.

-- 
-- Stephe

Re: RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS)

[Simon Clubley]

On 10 Sep 2001 15:29:45 -0400, in article <uelpehmja.fsf@gsfc.nasa.gov>, Stephen
Leake wrote:
>
>Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:
>
>> <snip> 
>> The situation's a bit more complicated than that. :-)
>> 
>> OARcorp _do_ support Ada as a development environment for RTEMS. However,
>> some of the BSP's (for example, the i386 BSP) have moved from COFF to ELF.
>
>Hmm. In my experience, a Board Support Package (BSP) is written in C,
>or Ada, or (most likely) Assembler. _not_ object code. 
>

In this case, the RTEMS BSP's are written in C.

>So what does it mean that a BSP has "moved from COFF to ELF"? 
>
>Maybe the BSP defines the loader, and it needs to know the object file
>format. I guess that would make sense.
>

Yes, I was not precise enough here. Your description above is closer, although
as I have not yet successfully built RTEMS with Ada support and as my
background is VMS and not Unix, I am still a little unsure on the fine
details. My understanding is that, amongst other things, a specific BSP's
build environment is designed differently depending on if COFF or ELF
formats are in use.

>> The current GCC used for GNAT, 2.8.x, generates COFF format
>> binaries. 
>
>This is misleading. GCC, the compiler, does not generate binaries; it
>generates Assembler code. The system assembler and linker generate
>binaries. If using the Gnu assembler and linker, they come from the
>binutils package, not the gcc package. So just because GNAT uses gcc
>2.8.1, does not mean RTEMS can't use it with binutils 2.11 (latest on
>Gnu site).
>
>I suppose there may be some upward incompatibilities, but I'd be
>surprised.
>

I do know that when I attempted to do just this (with or without the OARcorp
supplied patches to the gcc/gnat/binutils sources), in order to get pre-ELF
versions of the i386 BSP working with GNAT, then the build failed in
various ways.

>> It has been commented on several times in the RTEMS mailing list
>> that OARcorp are eagerly awaiting for ACT to deliver a GNAT for GCC
>> 3.x. :-)
>
>They don't have to use only the binary distributions from ACT! I would
>consider it part of a 3rd parties job, to repackage things for exactly
>this kind of reason.

I never implied that they were waiting for a binary distribution. :-)
Like the rest of us, I understand they are waiting for ACT to release a
source distribution. OARcorp do optionally build some binary environments
for easy installation, but generally RTEMS is built from source and a
GNAT cross-compiler (or just GCC if you are not interested in using Ada with
RTEMS) is also built from source as part of the installation.

>
>-- 
>-- Stephe

Simon.

PS: Once again, I am not associated with OARcorp in any way apart from an
interest in RTEMS.

-- 
Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFP
In the task of removing Microsoft from the marketplace, I have discovered a
truly remarkable plan, but this signature is too small to contain it.

Re: RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS)

[Joel Sherrill]

Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> wrote in message news:<Vt2n7.2101$%u4.2249@www.newsranger.com>...
> On Sun, 9 Sep 2001 22:20:33 -0500, in article
> <9nhbjd$dcg$1@suaar1aa.prod.compuserve.com>, Michael Garrett wrote:
> >
> >OAR had an Ada version of the RTEMS operating system a while back. I think
> >they have dropped support
> >for it, but I'm sure the source is available from them. This would probably
> >be a good starting point.
> >
> >Michael C. Garrett
> 
> The situation's a bit more complicated than that. :-)
> 
> OARcorp _do_ support Ada as a development environment for RTEMS. However,
> some of the BSP's (for example, the i386 BSP) have moved from COFF to ELF.
> 
> The current GCC used for GNAT, 2.8.x, generates COFF format binaries. It has
> been commented on several times in the RTEMS mailing list that OARcorp are
> eagerly awaiting for ACT to deliver a GNAT for GCC 3.x. :-)

I must have repeated that a lot because you nailed it. :)

But gcc 2.8.1 did support elf for the sparc and powerpc so it has
not been that difficult to try those out.  In fact, I recently 
tested 3.13p for the PowerPC and posted ACATS results
to the RTEMS users list.  They were quite good.  The sparc results
were also good although the sparc backend now makes some Solaris
dependent calls. :(  

We made RPMs available for GNAT/RTEMS 3.13p targetting the PowerPC
and they are at ...

ftp://ftp.oarcorp.com/pub/rtems/snapshots/ada_tools/gnat-3.13p-2

These support the latest development snapshots of RTEMS.  

> Simon.
> 
> PS: I am not associated with OARcorp in any way apart from wanting to use
> Ada with RTEMS...

And although I AM associated with OARcorp, I personally I want to see Ada
and RTEMS work together also.  :)

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

I'm aware of RTEMS - it might make "A Good Start". My recollection of what
it was all about was that it might be a bit limited for a full-up OS. More
like an RTK and some device drivers to support an Ada implementation on a
bare board.

There might be licensing issues as well. I believe it is GPL - don't know
the specifics - but it might not be A Good Thing to force any additional
work to fall under the GPL. (That's an opinion - others may differ on 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/


"Michael Garrett" <michaelgarrett@csi.com> wrote in message
news:9nhbjd$dcg$1@suaar1aa.prod.compuserve.com...
> OAR had an Ada version of the RTEMS operating system a while back. I think
> they have dropped support
> for it, but I'm sure the source is available from them. This would
probably
> be a good starting point.
>

Re: Ada OS talk (was: Progress on AdaOS)

[Joel Sherrill]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9nigt5$490$1@nh.pace.co.uk>...
> I'm aware of RTEMS - it might make "A Good Start". My recollection of what
> it was all about was that it might be a bit limited for a full-up OS. More
> like an RTK and some device drivers to support an Ada implementation on a
> bare board.

Correct RTEMS is what used to be called an executive or kernel.  It is
not as limited as you might think though with major features like 
TCP/IP, filesystem, about 85% of POSIX 1003.1b, uITRON, and a pSOS+-like API 
ported to about a dozen CPUs.

> There might be licensing issues as well. I believe it is GPL - don't know
> the specifics - but it might not be A Good Thing to force any additional
> work to fall under the GPL. (That's an opinion - others may differ on that.)

RTEMS is GPL'ed with the same type of exception as the GNAT run-time.

> 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/
> 
> 
> "Michael Garrett" <michaelgarrett@csi.com> wrote in message
> news:9nhbjd$dcg$1@suaar1aa.prod.compuserve.com...
> > OAR had an Ada version of the RTEMS operating system a while back. I think
> > they have dropped support
> > for it, but I'm sure the source is available from them. This would
>  probably
> > be a good starting point.

It has been a long time but it can be dug up. :)  

When it was new, there was very little 
feedback to it.  The C implementation got a lot more interest
and when the C version was used as the run-time for GNAT,
it seemed to satisfy the same goal without duplicating 
effort.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Ada OS talk (was: Progress on AdaOS)

[Michael Garrett]

I may not understand the whole picture.... ( been in managment for a while )
but
the original Ada version of rtems could be put on top of a hardware
abstraction layer, with minimal
amount of assembly, ( it probably was impelmented this way ) forming a micro
kernel, which could be the foundation of the operating system.

With suitable layers on top of this foundation ( GNORT compiled, or no
runtime ), a runtime could be provided that GNAT could call into, providing
a full Ada runtime environment on top of an all Ada kernel.

( I'm in over my head but you get the picture ).

What I think this would provide is deterministic behavior. If an all Ada OS
is to be considered, my opinion
is that it should be deterministic to a hard realtime level. This is a lofty
goal, but starting with a deterministic
all Ada micro kernel is  a good start.

QNX is built this way, on top of a small scalable micro kernel. If the goal
is an all Ada scalable OS this seems
to be an ideal way to leverage the work already done by OAR, the all Ada
micro kernel.



Michael C. Garrett
michaelgarrett@csi.com

Joel Sherrill <joel@OARcorp.com> wrote in message
news:608f3869.0109101239.5b9fdde2@posting.google.com...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:<9nigt5$490$1@nh.pace.co.uk>...
> > I'm aware of RTEMS - it might make "A Good Start". My recollection of
what
> > it was all about was that it might be a bit limited for a full-up OS.
More
> > like an RTK and some device drivers to support an Ada implementation on
a
> > bare board.
>
> Correct RTEMS is what used to be called an executive or kernel.  It is
> not as limited as you might think though with major features like
> TCP/IP, filesystem, about 85% of POSIX 1003.1b, uITRON, and a pSOS+-like
API
> ported to about a dozen CPUs.
>
> > There might be licensing issues as well. I believe it is GPL - don't
know
> > the specifics - but it might not be A Good Thing to force any additional
> > work to fall under the GPL. (That's an opinion - others may differ on
that.)
>
> RTEMS is GPL'ed with the same type of exception as the GNAT run-time.
>
> > 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/
> >
> >
> > "Michael Garrett" <michaelgarrett@csi.com> wrote in message
> > news:9nhbjd$dcg$1@suaar1aa.prod.compuserve.com...
> > > OAR had an Ada version of the RTEMS operating system a while back. I
think
> > > they have dropped support
> > > for it, but I'm sure the source is available from them. This would
> >  probably
> > > be a good starting point.
>
> It has been a long time but it can be dug up. :)
>
> When it was new, there was very little
> feedback to it.  The C implementation got a lot more interest
> and when the C version was used as the run-time for GNAT,
> it seemed to satisfy the same goal without duplicating
> effort.
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel@OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985

Re: Ada OS talk (was: Progress on AdaOS)

[David Starner]

On Fri, 7 Sep 2001 10:24:04 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> To design and build a full-blown file system is a *big* job. Just look at
> everything that is in NTFS.

Based on what people have mentioned about NTFS, it has serious feature 
bloat; having features that can't be accessed from the API are a waste.
I wasn't talking about implementing a journalled, efficent filesystem
from the start; I was talking about implementing a quick and dirty 
filesystem that reflects the way the OS works.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Ada OS talk (was: Progress on AdaOS)

[Darren New]

> > Right. The hardware is going to enforce this. But I don't want to reveal
> > a storage-element level as a building block for directories, for
> > example.
> 
> You are thinking Unix again ;-)  Dont!

Well, no, avoiding recreating UNIX is just what I've been advocating. My
point is that saying "everything is based on storage elements" is
pointless if at some point you hide storage elements from the
application. Just like if you support demand-paged virtual memory, you
hide physical memory addresses from applications. Of course, a kernel is
going to know about physical memory addresses, as it's the one doing the
paging. But the API to the kernel need never know about physical memory
addresses. (At least for things like desktop apps. Of course, realtime
apps etc might want that info.)

> > > By serialization you mean a (do_first, do_next, end_error) sort of thing?
> > No, I mean flattening into something that has to be parsed.
> OK.  Them it is definitely an outer layer (w.r.t. the kernel).

Sorry. I'm not sure what that means.
 
> > > I think the best building block is the (un)bounded array of storage
> > > elements, which is more than this.  But of course I may be wrong.
> >
> > It's a good low-level building block, but it's not a good higher-level
> > building block. I think records are good. I think the ability to insert
> > and delete records is good. I think the ability to have at least one and
> > maybe many ordered indicies on records is good.
> 
> I meant the best _low_level_ building block.  Then a middle level layer
> would provide records etc. but this edifice needs bricks.

Well, considering that I don't know of any memory hardware that isn't
based on some equivalent of storage elements, this is a kind of
meaningless statement, yes? "We should base our operating system on
assuming the hardware has RAM."  Errr, OK. Sure.

I was discussing what kind of API the OS and/or kernel should present to
application programs.

Am I misunderstanding your point?

> The point was that _both_ directories and file types are similarly above
> kernel level, without hindering coherency or performance.

Well, actually, I thought that was the question being discussed. Namely,
what *is* the kernel layer?

> Not important an issue really at this point.  Hmmm... what point?  I would
> expect this talk would result in a sort of strategic plan for building an
> OS as a hobby by Adaists.  To that effect I propose a generic principle of
> simplicity/smallness.  That is why my messages have a general "downsizing"
> tone.  Remember the fall of the AdaOS.

Yes. But nothing I've suggested is really radical or complicated. Poorly
described, perhaps.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[Dmitry A. Kazakov]

On Fri, 31 Aug 2001 17:58:00 GMT, Darren New <dnew@san.rr.com> wrote:

>"M. A. Alves" wrote:
>> 
>> > If you're building an AdaOS, why not make files that are managed with
>> > Ada semantics?
>> 
>> My view is close to that.  ADTs.  File = persistent (un)bounded array of
>> storage element (plus user and permission information).  Dir = persistent
>> (un)bounded array of files (plus ditto).
>
>But why limit a file to an array of storage elements? Why not persistant
>unbounded storage pool? Or persistant unbounded tagged classwide type?
>Or persistant protected object? (Ada already has the concept of a
>persistant storage mechanism, pragma shared_passive. Why not use that?)

Amen.

I would like to add, why to have files at all? There should be only
objects allocated in one big virtual memory chunk. 64-bit address
space allows to address every objects in every computer of the world.
There should be no I/O, only memory mapping.

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Chad R. Meiners]

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3b913376.333516@news.cis.dfn.de...
>
> Amen.
>
> I would like to add, why to have files at all? There should be only
> objects allocated in one big virtual memory chunk. 64-bit address
> space allows to address every objects in every computer of the world.
> There should be no I/O, only memory mapping.
>
> Regards,
> Dmitry Kazakov

So once the data collections get larger than available RAM, the sorting
algorithms suffer?

Re: Progress on AdaOS

[Dmitry A. Kazakov]

On Sat, 1 Sep 2001 21:09:16 -0400, "Chad R. Meiners"
<crmeiners@hotmail.com> wrote:

>
>"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
>news:3b913376.333516@news.cis.dfn.de...
>>
>> Amen.
>>
>> I would like to add, why to have files at all? There should be only
>> objects allocated in one big virtual memory chunk. 64-bit address
>> space allows to address every objects in every computer of the world.
>> There should be no I/O, only memory mapping.
>
>So once the data collections get larger than available RAM, the sorting
>algorithms suffer?

If the data are processed consequently as it is usually made when data
amount is large, then the virtual memory pages will be loaded and
stored also consequently. If it is not so, then I/O model faces same
problem.

Of course, for big, complex, concurrently accessed data structures
there should be an interface to access them. Ada is very good for it.

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Jean-Pierre Rosen]

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


"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> a �crit dans le message news: 3b913376.333516@news.cis.dfn.de...
> I would like to add, why to have files at all? There should be only
> objects allocated in one big virtual memory chunk. 64-bit address
> space allows to address every objects in every computer of the world.
> There should be no I/O, only memory mapping.
>
Your dream OS has a name: Multics

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Progress on AdaOS

[Dmitry Kazakov]

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

On Mon, 3 Sep 2001 08:39:22 +0200, "Jean-Pierre Rosen"
<rosen@adalog.fr> wrote:

>
>"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> a �crit dans le message news: 3b913376.333516@news.cis.dfn.de...
>> I would like to add, why to have files at all? There should be only
>> objects allocated in one big virtual memory chunk. 64-bit address
>> space allows to address every objects in every computer of the world.
>> There should be no I/O, only memory mapping.
>>
>Your dream OS has a name: Multics

But it isn't written in Ada. Right? (:-))

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[M. A. Alves]

> >But why limit a file to an array of storage elements? Why not persistant
> >unbounded storage pool? Or persistant unbounded tagged classwide type?
> >Or persistant protected object? (Ada already has the concept of a
> >persistant storage mechanism, pragma shared_passive. Why not use that?)
>
> Amen.
>
> I would like to add, why to have files at all? There should be only
> objects allocated in one big virtual memory chunk. 64-bit address
> space allows to address every objects in every computer of the world.
> There should be no I/O, only memory mapping.

Yes!  With each memory cell classified according to:

  * readable or not
  * writeable or not
  * timeable access or not (for real time computations)
  * persistency
  * ...

With the proper methods and exceptions e.g. Put, Get, Read_Error, etc.

Some mixin, it appears.

You still have _devices_.  All cells in the same device would have the
same class(ification).  In fact all there is is devices, not computers, as
a computer is a set of devices.  So each device in the world would have an
id (some already do) and so each cell in the world has id (device_id,
cell_number) or so.  But a 50/50 partition of the 64-bit addressing gives
c. 1 million devices with 1 million cells each:  not enough.  Go for
128-bit, 1 billion devices of 1 billion cells each.  And I feel even that
is a bit tight.  256-bit?

Now, "mapping".  The OS would have device interfaces (libraries), and an
"overall" layer providing the universal mapping.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Progress on AdaOS

[Dmitry Kazakov]

On Mon, 3 Sep 2001 19:16:11 +0000 (GMT), "M. A. Alves"
<maa@liacc.up.pt> wrote:

>> >But why limit a file to an array of storage elements? Why not persistant
>> >unbounded storage pool? Or persistant unbounded tagged classwide type?
>> >Or persistant protected object? (Ada already has the concept of a
>> >persistant storage mechanism, pragma shared_passive. Why not use that?)
>>
>> Amen.
>>
>> I would like to add, why to have files at all? There should be only
>> objects allocated in one big virtual memory chunk. 64-bit address
>> space allows to address every objects in every computer of the world.
>> There should be no I/O, only memory mapping.
>
>Yes!  With each memory cell classified according to:
>
>  * readable or not
>  * writeable or not
>  * timeable access or not (for real time computations)
>  * persistency
>  * ...

I think in an OO OS there should be more fine grained properties. For
instance there should be different access policies regarding the
object itself and its methods. For instance, an object created by a
more privileged user [object] might have methods available for less
privileged users [object]. Further, these methods can be executed
either on the caller's or callee's [supervisor calls] contexts etc
etc.

>With the proper methods and exceptions e.g. Put, Get, Read_Error, etc.
>
>Some mixin, it appears.
>
>You still have _devices_.  All cells in the same device would have the
>same class(ification).  In fact all there is is devices, not computers, as
>a computer is a set of devices.  So each device in the world would have an
>id (some already do) and so each cell in the world has id (device_id,
>cell_number) or so.  But a 50/50 partition of the 64-bit addressing gives
>c. 1 million devices with 1 million cells each:  not enough.  Go for
>128-bit, 1 billion devices of 1 billion cells each.  And I feel even that
>is a bit tight.  256-bit?
>
>Now, "mapping".  The OS would have device interfaces (libraries), and an
>"overall" layer providing the universal mapping.

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Darren New]

> I think in an OO OS there should be more fine grained properties. For
> instance there should be different access policies regarding the
> object itself and its methods. For instance, an object created by a
> more privileged user [object] might have methods available for less
> privileged users [object]. Further, these methods can be executed
> either on the caller's or callee's [supervisor calls] contexts etc
> etc.

You're going too much back into traditional OSes. An OO OS works quite
well when modeled with capabilities. Generally, you can easily model a
capability as an address+password. Say, a 64-bit address concatenated
with a 64-bit "password" of random bits that the object can check for
validity. Different passwords on the same address give you the varying
privledge levels you're looking for. (64 is probably too small a number
for either of those, these days.)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[Dmitry A. Kazakov]

On Wed, 05 Sep 2001 16:37:03 GMT, Darren New <dnew@san.rr.com> wrote:

>> I think in an OO OS there should be more fine grained properties. For
>> instance there should be different access policies regarding the
>> object itself and its methods. For instance, an object created by a
>> more privileged user [object] might have methods available for less
>> privileged users [object]. Further, these methods can be executed
>> either on the caller's or callee's [supervisor calls] contexts etc
>> etc.
>
>You're going too much back into traditional OSes. An OO OS works quite
>well when modeled with capabilities. Generally, you can easily model a
>capability as an address+password. Say, a 64-bit address concatenated
>with a 64-bit "password" of random bits that the object can check for
>validity. Different passwords on the same address give you the varying
>privledge levels you're looking for. (64 is probably too small a number
>for either of those, these days.)

That's not safe, because the "password" and the code that checks can
be faked.

It is generally no problem if object's code is executed on the
caller's context. An exception may in worst case destroy the caller.
But definitely there should be objects with methods executed on some
more privileged context, no matter if the object itself exists in the
caller's one.

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Darren New]

> That's not safe, because the "password" and the code that checks can
> be faked.

Well, you have to make sure that doesn't happen. Certainly something
like a capability to a file is going to be checked by the file
server/process, not by the application trying to open the file.
 
> It is generally no problem if object's code is executed on the
> caller's context. An exception may in worst case destroy the caller.

Well, uh, .... obviously a capability is an access control mechanism.
You don't have access control protecting you from yourself. So a system
using capabilities is going to have some alternate access controls (such
as memory mapping or compiled-in array bounds checking, etc) that keeps
you from simply inspecting the code of the process that actually
supplies the service denoted by the capability.

Check out the EROS web site. Your objections don't make any sense in
context. And I can't figure out what context they would make sense in.

> But definitely there should be objects with methods executed on some
> more privileged context, no matter if the object itself exists in the
> caller's one.

Well, maybe not "more privledged". Maybe "differently privledged".

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Progress on AdaOS

[Dmitry Kazakov]

On Thu, 06 Sep 2001 16:35:21 GMT, Darren New <dnew@san.rr.com> wrote:

>> That's not safe, because the "password" and the code that checks can
>> be faked.
>
>Well, you have to make sure that doesn't happen. Certainly something
>like a capability to a file is going to be checked by the file
>server/process, not by the application trying to open the file.
> 
>> It is generally no problem if object's code is executed on the
>> caller's context. An exception may in worst case destroy the caller.
>
>Well, uh, .... obviously a capability is an access control mechanism.
>You don't have access control protecting you from yourself. So a system
>using capabilities is going to have some alternate access controls (such
>as memory mapping or compiled-in array bounds checking, etc) that keeps
>you from simply inspecting the code of the process that actually
>supplies the service denoted by the capability.

If there is "a process that supplies a service", then it is another
process, i.e. the method is executed on another context. This is
another case and a heavy weighted one. It would be very inefficient to
have a separate process for every object. This will also exclude
passive objects [= Ada protected objects] which have no task
associated with.

>Check out the EROS web site. Your objections don't make any sense in
>context. And I can't figure out what context they would make sense in.

There is a general problem how to protect private parts [routines and
data]. In an Ada program, the compiler protects you. This level is not
enough safe for an OS.

>> But definitely there should be objects with methods executed on some
>> more privileged context, no matter if the object itself exists in the
>> caller's one.
>
>Well, maybe not "more privledged". Maybe "differently privledged".

No matter. The rule is one cannot gain more privileges than granted.

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Darren New]

> If there is "a process that supplies a service", then it is another
> process, i.e. the method is executed on another context.

I'm not sure how you would enforce any sort of access control in the
case of only having one context, actually.

> This is
> another case and a heavy weighted one. It would be very inefficient to
> have a separate process for every object.

It doesn't need to be a separate process for every object. Indeed, in
Ameoba (Tannenbaum's OS), all the files are managed by one process. You
have a capability for each file, a capability for each server, a
capability for each directory, a capability for each process (so you can
kill it, debug it, etc), and so on. 

You don't have a capability for each array or tagged object, for
example, because you're not trying to protect them from yourself.

I think I see what you're saying. An "OO" operating system isn't one in
which every programming-language-level object is an OS-managed resource.
An "OO" operating system is one where the data and the routines to
manipulate that data are bundled together. E.g., where an image file
provides the routines for getting and setting pixels, rather than being
represented as an array of storage elements and an independent library
for treating an array of storage elements as an image.

> This will also exclude
> passive objects [= Ada protected objects] which have no task
> associated with.

I think if you have the protected object in your data space, there's not
much point in enforcing an administrative limitation on who can get to
it. On the other hand, if your hardware supports capabilities directly,
then there's no problem with doing this. 

Think of a capability as vaguely similar to a trap instruction, perhaps.
You're granted a capability by the OS putting the address of the routine
to call into the interrupt vectors where you can get to it with a system
trap. The OS then checks that your arguments are legal. Same thing.
 
> >Check out the EROS web site. Your objections don't make any sense in
> >context. And I can't figure out what context they would make sense in.
> 
> There is a general problem how to protect private parts [routines and
> data]. In an Ada program, the compiler protects you. This level is not
> enough safe for an OS.

Burroughs seemed to make it work just fine.

> >> But definitely there should be objects with methods executed on some
> >> more privileged context, no matter if the object itself exists in the
> >> caller's one.
> >
> >Well, maybe not "more privledged". Maybe "differently privledged".
> 
> No matter. The rule is one cannot gain more privileges than granted.

Right. And capabilities are one way of doing this.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
    Those who work hard with few results always 
           value hard work over getting results.

Re: Progress on AdaOS

[Dmitry A. Kazakov]

On Fri, 07 Sep 2001 15:58:30 GMT, Darren New <dnew@san.rr.com> wrote:

>> If there is "a process that supplies a service", then it is another
>> process, i.e. the method is executed on another context.
>
>I'm not sure how you would enforce any sort of access control in the
>case of only having one context, actually.

Well there should be several contexts of one process. For instance,
let an application owns a "safe" object. It is safe in the sense that
its data cannot be accessed otherwise than through the object's
methods. To enforce this the corresponding memory pages should be
normally inacessible for [read/]write. However when an object's method
is called, there should be a context switch upon the call that would
make the memory pages accessible for read/write. Upon return the
context is switched back.

I very like the idea, someone mentioned in a parallel thread, that the
access rights can be made dependant on the page the PC points to.

>> This is
>> another case and a heavy weighted one. It would be very inefficient to
>> have a separate process for every object.
>
>It doesn't need to be a separate process for every object. Indeed, in
>Ameoba (Tannenbaum's OS), all the files are managed by one process.

It is no matter one or many. It is like the difference between
rendezvous and protected objects. You simply need both of them because
rendezvous are inherently slow when compared with protected objects
and yet not all necessary things can be made using solely protected
objects.

>You have a capability for each file, a capability for each server, a
>capability for each directory, a capability for each process (so you can
>kill it, debug it, etc), and so on. 

It is OK to me.

>You don't have a capability for each array or tagged object, for
>example, because you're not trying to protect them from yourself.

Yes, but there are exceptions. Consider an object OpenKeyPair given to
an application. The application is allowed to use its public methods
(Code/Sign/Encode), but it cannot read its data, create a copy of it
or pass it to another application.

I have nothing against capacities if they allow to have access rights
to object's methods and members dependent on the access level to the
object itself. [Of course only "safe" objects are considered.]

>> This will also exclude
>> passive objects [= Ada protected objects] which have no task
>> associated with.
>
>I think if you have the protected object in your data space, there's not
>much point in enforcing an administrative limitation on who can get to
>it. On the other hand, if your hardware supports capabilities directly,
>then there's no problem with doing this. 

IMO it is very important to have *safe* objects living in the process
space, because then a lot of things could be made within the process
time quant, which otherwise would be served by some driver, ACP etc,
with a catastrophic impact on real-time issues.

>Think of a capability as vaguely similar to a trap instruction, perhaps.
>You're granted a capability by the OS putting the address of the routine
>to call into the interrupt vectors where you can get to it with a system
>trap. The OS then checks that your arguments are legal. Same thing.

Agree. It is how it could be implemented in a machine of usual
achitecture. Maybe sometimes CPUs will support type tags, then... [at
least 15 years old idea] (:-))

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Darren New]

> >> If there is "a process that supplies a service", then it is another
> >> process, i.e. the method is executed on another context.
> >
> >I'm not sure how you would enforce any sort of access control in the
> >case of only having one context, actually.
> 
> Well there should be several contexts of one process.

Then you can use capabilities between those contexts with low overhead.

> For instance,
> let an application owns a "safe" object. It is safe in the sense that
> its data cannot be accessed otherwise than through the object's
> methods.

OK. That means that to get to this object, you need to trap into the
kernel to change the memory protection. (Or you need more sophisticated
hardware, sure.)

> To enforce this the corresponding memory pages should be
> normally inacessible for [read/]write. However when an object's method
> is called, there should be a context switch upon the call that would
> make the memory pages accessible for read/write. Upon return the
> context is switched back.

I'm not sure how this is more efficient than two separate processes, if
your hardware requires you to do context switches to change the memory
mapping. It's two separate contexts in one process, but it's only
incidental that it's one process. (Actually, it's kind of pushing the
limitations of the definition of "process" I think.)
 
> I very like the idea, someone mentioned in a parallel thread, that the
> access rights can be made dependant on the page the PC points to.

Yeah. As an aside, I thought of doing this under CP/M about 20 years
ago. Never got around to it, tho. :-)
 
> >> This is
> >> another case and a heavy weighted one. It would be very inefficient to
> >> have a separate process for every object.
> >
> >It doesn't need to be a separate process for every object. Indeed, in
> >Ameoba (Tannenbaum's OS), all the files are managed by one process.
> 
> It is no matter one or many. It is like the difference between
> rendezvous and protected objects. You simply need both of them because
> rendezvous are inherently slow when compared with protected objects
> and yet not all necessary things can be made using solely protected
> objects.

If you're trapping to the kernel to change memory protection in order to
do your call, I'm not sure what the efficiency benefits are between
doing that in one "process" or in two, especially if the two processes
can share memory to pass parameters and such.

> >You don't have a capability for each array or tagged object, for
> >example, because you're not trying to protect them from yourself.
> 
> Yes, but there are exceptions. Consider an object OpenKeyPair given to
> an application. The application is allowed to use its public methods
> (Code/Sign/Encode), but it cannot read its data, create a copy of it
> or pass it to another application.

Then you need to put it in a different process, if your definition of
"process" is "all the code that can get to the same memory areas". If
that's not your definition, then you need to define clearly what you
mean by a "process". :-)

> I have nothing against capacities if they allow to have access rights
> to object's methods and members dependent on the access level to the
> object itself. [Of course only "safe" objects are considered.]

Yes, of course they do. Many capabilities can be served by the same
object. A file could have a read capability, a write capability, and a
delete capability. If you look at the file server as the "object", then
all the files on that file server are access to different methods and
data members.
 
> >I think if you have the protected object in your data space, there's not
> >much point in enforcing an administrative limitation on who can get to
> >it. On the other hand, if your hardware supports capabilities directly,
> >then there's no problem with doing this.
> 
> IMO it is very important to have *safe* objects living in the process
> space, because then a lot of things could be made within the process
> time quant, which otherwise would be served by some driver, ACP etc,
> with a catastrophic impact on real-time issues.

Then you need to enforce it differently. You either need very
sophisticated access control hardware, or you need to have the compiler
generate code that enforces this and prevent users from disabling that
code in any way.

> Agree. It is how it could be implemented in a machine of usual
> achitecture. Maybe sometimes CPUs will support type tags, then... [at
> least 15 years old idea] (:-))

Or use the Hermes/NIL ideology, and let users only use high-level
languages that enforce pointer checking, array bounds checking, and etc.
But if you use capabilities as part of your IPC, you don't really need
to do this. 

I think no matter how you slice it, you're not going to be able to put
"safe" objects in a process if the user's allowed to use assembler and
you define "process" as "accessible memory space plus one or more
threads".

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
    Those who work hard with few results always 
           value hard work over getting results.

Re: Progress on AdaOS

[Larry Kilgallen]

In article <3B9ACEB6.7F06DF1D@san.rr.com>, Darren New <dnew@san.rr.com> writes:

>> I very like the idea, someone mentioned in a parallel thread, that the
>> access rights can be made dependant on the page the PC points to.

I thought the goal of the exercise was to run on existing hardware.

> If you're trapping to the kernel to change memory protection in order to
> do your call, I'm not sure what the efficiency benefits are between
> doing that in one "process" or in two, especially if the two processes
> can share memory to pass parameters and such.


Ignore efficiency and think about security.

Using inner mode guarantees that the caller cannot modify the parameters
after they have been vetted by the privileged code and before they
have been copied for use by the privileged code.  And regardless of
who is sharing what memory, the privileged code must have a private
copy before execution returns to the unprivileged caller.

Re: Progress on AdaOS

[Dmitry A. Kazakov]

On Sun, 09 Sep 2001 02:06:50 GMT, Darren New <dnew@san.rr.com> wrote:

>> For instance,
>> let an application owns a "safe" object. It is safe in the sense that
>> its data cannot be accessed otherwise than through the object's
>> methods.
>
>OK. That means that to get to this object, you need to trap into the
>kernel to change the memory protection. (Or you need more sophisticated
>hardware, sure.)

Yes, I must go through the kernel.

>> To enforce this the corresponding memory pages should be
>> normally inacessible for [read/]write. However when an object's method
>> is called, there should be a context switch upon the call that would
>> make the memory pages accessible for read/write. Upon return the
>> context is switched back.
>
>I'm not sure how this is more efficient than two separate processes, if
>your hardware requires you to do context switches to change the memory
>mapping. It's two separate contexts in one process, but it's only
>incidental that it's one process. (Actually, it's kind of pushing the
>limitations of the definition of "process" I think.)

No queues and no scheduling.

>> I very like the idea, someone mentioned in a parallel thread, that the
>> access rights can be made dependant on the page the PC points to.
>
>Yeah. As an aside, I thought of doing this under CP/M about 20 years
>ago. Never got around to it, tho. :-)

That guy claimed that it is possible, efficient and _made_. Maybe he
meant some special hardware, or?

>> >> This is
>> >> another case and a heavy weighted one. It would be very inefficient to
>> >> have a separate process for every object.
>> >
>> >It doesn't need to be a separate process for every object. Indeed, in
>> >Ameoba (Tannenbaum's OS), all the files are managed by one process.
>> 
>> It is no matter one or many. It is like the difference between
>> rendezvous and protected objects. You simply need both of them because
>> rendezvous are inherently slow when compared with protected objects
>> and yet not all necessary things can be made using solely protected
>> objects.
>
>If you're trapping to the kernel to change memory protection in order to
>do your call, I'm not sure what the efficiency benefits are between
>doing that in one "process" or in two, especially if the two processes
>can share memory to pass parameters and such.

In general same as with rendezvous and protected objects. Ada
Rationale explains it excelently.

>> >You don't have a capability for each array or tagged object, for
>> >example, because you're not trying to protect them from yourself.
>> 
>> Yes, but there are exceptions. Consider an object OpenKeyPair given to
>> an application. The application is allowed to use its public methods
>> (Code/Sign/Encode), but it cannot read its data, create a copy of it
>> or pass it to another application.
>
>Then you need to put it in a different process, if your definition of
>"process" is "all the code that can get to the same memory areas". If
>that's not your definition, then you need to define clearly what you
>mean by a "process". :-)

To me process is mainly a subject of scheduling, like a task [maybe a
set of tasks]. I would like to have something less-weighted and data
oriented [vs. procedural processes]. Something that I would call
*safe* object, sort of DLL, but more secure.

>> I have nothing against capacities if they allow to have access rights
>> to object's methods and members dependent on the access level to the
>> object itself. [Of course only "safe" objects are considered.]
>
>Yes, of course they do. Many capabilities can be served by the same
>object. A file could have a read capability, a write capability, and a
>delete capability. If you look at the file server as the "object", then
>all the files on that file server are access to different methods and
>data members.

To me "read capability" is just a right to call the method "Read". It
should work so that each method and data member have a guard. A
caller/user should "bribe" that guard (:-)). So the set of
capabilities is potentially unlimited.

>> >I think if you have the protected object in your data space, there's not
>> >much point in enforcing an administrative limitation on who can get to
>> >it. On the other hand, if your hardware supports capabilities directly,
>> >then there's no problem with doing this.
>> 
>> IMO it is very important to have *safe* objects living in the process
>> space, because then a lot of things could be made within the process
>> time quant, which otherwise would be served by some driver, ACP etc,
>> with a catastrophic impact on real-time issues.
>
>Then you need to enforce it differently. You either need very
>sophisticated access control hardware,

Would be nice, but to be realistic I see no way other than a trap
based implementation.

>or you need to have the compiler
>generate code that enforces this and prevent users from disabling that
>code in any way.

No, that would be a MS-DOS with an Ada compiler.

>> Agree. It is how it could be implemented in a machine of usual
>> achitecture. Maybe sometimes CPUs will support type tags, then... [at
>> least 15 years old idea] (:-))
>
>Or use the Hermes/NIL ideology, and let users only use high-level
>languages that enforce pointer checking, array bounds checking, and etc.

IMO Any attempt to dictate user what he/she should use, would deem the
system. They would surely like to have a Java VM, Visual Basic and who
knows what else. Let them, but ensure that nothing they write in Basic
may crash the system if they run that crap with normal privilegies.

>But if you use capabilities as part of your IPC, you don't really need
>to do this. 
>
>I think no matter how you slice it, you're not going to be able to put
>"safe" objects in a process if the user's allowed to use assembler and
>you define "process" as "accessible memory space plus one or more
>threads".

Absolutely. A process should have several "views" on its memory space.
And a view change should go through the kernel.

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Darren New]

> Yes, I must go through the kernel.

OK, then capabilities will do the trick for you.
 
> No queues and no scheduling.

Not sure what kind of "queue" you're talking about, but OK. And the lack
of scheduling is possible with any non-blocking system call.
 
> >Yeah. As an aside, I thought of doing this under CP/M about 20 years
> >ago. Never got around to it, tho. :-)
> 
> That guy claimed that it is possible, efficient and _made_. Maybe he
> meant some special hardware, or?

Oh, I'm sure there's hardware to do it in some CPU architecture. It was
just easy to hang hardware off a 8080 that would do the same thing, is
all. I don't even remember why I wanted to do it.
 
> >If you're trapping to the kernel to change memory protection in order to
> >do your call, I'm not sure what the efficiency benefits are between
> >doing that in one "process" or in two, especially if the two processes
> >can share memory to pass parameters and such.
> 
> In general same as with rendezvous and protected objects. Ada
> Rationale explains it excelently.

Errr, well, not really. You're assuming the rendezvous does an argument
marshalling via streams, yes, at least for the distributed case? I think
the rendezvous is probably slow because of the context switches between
the different threads, but I'm not going to profess to know the details
of what an Ada compiler generates. :-)
 
> >Then you need to put it in a different process, if your definition of
> >"process" is "all the code that can get to the same memory areas". If
> >that's not your definition, then you need to define clearly what you
> >mean by a "process". :-)
> 
> To me process is mainly a subject of scheduling, like a task [maybe a
> set of tasks].

Usually, the difference between a "process" and a "task" is that a
process doesn't share memory with any other process. A "task" shares
memory with all the other tasks in the same process. However, now you've
moved away from the standard terminology, so saying "it's really the
same process, but with different memory access" means you need to define
precisely what you're talking about. :-)

> I would like to have something less-weighted and data
> oriented [vs. procedural processes]. Something that I would call
> *safe* object, sort of DLL, but more secure.

OK. Then what you're looking for can be done with capabilities, *if* you
have hardware to support them directly (like OO hardware might) or if
you want to have the kernel remapping memory permissions.
 
> >Yes, of course they do. Many capabilities can be served by the same
> >object. A file could have a read capability, a write capability, and a
> >delete capability. If you look at the file server as the "object", then
> >all the files on that file server are access to different methods and
> >data members.
> 
> To me "read capability" is just a right to call the method "Read". 

It's not a question of "to you", really. It's a well-defined term. But
yes, knowing the value of a capability that hasn't been revoked
generally gives you rights to do those things for which you have the
capability. If the owner of the object is coded to be able to give you a
read-only capability, then you can do what you say.

> It
> should work so that each method and data member have a guard. A
> caller/user should "bribe" that guard (:-)). So the set of
> capabilities is potentially unlimited.

Correct. That's why you need it at some user level, rather than
kernel-enforced.
 
> Would be nice, but to be realistic I see no way other than a trap
> based implementation.

Yes, unless you're going to design your own CPU. On the other hand,
that's not as outrageous nowadays as it might have been 10 years ago.
:-) It certainly wouldn't promote a hobbyist AdaOS, I'll grant. :-)
 
> >or you need to have the compiler
> >generate code that enforces this and prevent users from disabling that
> >code in any way.
> 
> No, that would be a MS-DOS with an Ada compiler.

Err, sorry? No, you'd have a Burroughs B-series. They worked it by
having privledged (think "setuid" type priveledge) programs which were
the only ones allowed to write "executable" code, and those programs
were responsible for making sure you didn't do the Wrong Thing.
 
> >Or use the Hermes/NIL ideology, and let users only use high-level
> >languages that enforce pointer checking, array bounds checking, and etc.
> 
> IMO Any attempt to dictate user what he/she should use, would deem the
> system. They would surely like to have a Java VM, Visual Basic and who
> knows what else. Let them, but ensure that nothing they write in Basic
> may crash the system if they run that crap with normal privilegies.

Yes. And you can do this by either using hardware protection, or using a
VB interpreter that doesn't let them run off the end of arrays. The
JavaVM (other than JNI etc) certainly doesn't need hardware support to
keep you from doing something nasty - that's the whole idea of the
sandbox.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
    Those who work hard with few results always 
           value hard work over getting results.

Re: Progress on AdaOS

[Dmitry A. Kazakov]

On Sun, 09 Sep 2001 20:35:57 GMT, Darren New <dnew@san.rr.com> wrote:

>> >Then you need to put it in a different process, if your definition of
>> >"process" is "all the code that can get to the same memory areas". If
>> >that's not your definition, then you need to define clearly what you
>> >mean by a "process". :-)
>> 
>> To me process is mainly a subject of scheduling, like a task [maybe a
>> set of tasks].
>
>Usually, the difference between a "process" and a "task" is that a
>process doesn't share memory with any other process. A "task" shares
>memory with all the other tasks in the same process.

Yes, I said "like a task" because of this difference. A process is a
safe task.

>However, now you've
>moved away from the standard terminology, so saying "it's really the
>same process, but with different memory access" means you need to define
>precisely what you're talking about. :-)

I many OSes a process may have several tasks [threads]. Why not to
have several memory mappings as well?

>> I would like to have something less-weighted and data
>> oriented [vs. procedural processes]. Something that I would call
>> *safe* object, sort of DLL, but more secure.
>
>OK. Then what you're looking for can be done with capabilities, *if* you
>have hardware to support them directly (like OO hardware might) or if
>you want to have the kernel remapping memory permissions.

Yes.

>> It
>> should work so that each method and data member have a guard. A
>> caller/user should "bribe" that guard (:-)). So the set of
>> capabilities is potentially unlimited.
>
>Correct. That's why you need it at some user level, rather than
>kernel-enforced.

Why not? Could a capacity be represented by a tagged type, and so that
dispatch [sometimes] happens on the kernel context? Of course if an
object is declared on the user level there is little sense to check
its capacities on a more secure level. But there will be system
objects too.

>> >or you need to have the compiler
>> >generate code that enforces this and prevent users from disabling that
>> >code in any way.
>> 
>> No, that would be a MS-DOS with an Ada compiler.
>
>Err, sorry? No, you'd have a Burroughs B-series. They worked it by
>having privledged (think "setuid" type priveledge) programs which were
>the only ones allowed to write "executable" code, and those programs
>were responsible for making sure you didn't do the Wrong Thing.
>
>> >Or use the Hermes/NIL ideology, and let users only use high-level
>> >languages that enforce pointer checking, array bounds checking, and etc.
>> 
>> IMO Any attempt to dictate user what he/she should use, would deem the
>> system. They would surely like to have a Java VM, Visual Basic and who
>> knows what else. Let them, but ensure that nothing they write in Basic
>> may crash the system if they run that crap with normal privilegies.
>
>Yes. And you can do this by either using hardware protection, or using a
>VB interpreter that doesn't let them run off the end of arrays. The
>JavaVM (other than JNI etc) certainly doesn't need hardware support to
>keep you from doing something nasty - that's the whole idea of the
>sandbox.

What about hardware/software faults? I do not very believe in pure
software protection. In any case the protection should be deeply
echeloned.

Regards,
Dmitry Kazakov

Re: Progress on AdaOS

[Darren New]

> I many OSes a process may have several tasks [threads]. Why not to
> have several memory mappings as well?

Nothing wrong with that. It's just not what the word "process"
classically means.
 
> >Correct. That's why you need it at some user level, rather than
> >kernel-enforced.
> 
> Why not? Could a capacity be represented by a tagged type, and so that
> dispatch [sometimes] happens on the kernel context?

Well, if I have a tagged type that dispatches to the kernel, and there's
three inherited procedures, and you only want the holder of the tagged
object to be able to dispatch to one of them, you're going to have
trouble. Maybe all three will dispatch to the kernel, and the kernel
will decide that two of them are erroneous and should raise
Capability_Error or something, but then that's a user-level check,
rather than a hardware check. The fact that the code is running with
kernel permissions doesn't change the fact that it's software doing the
checking, which is what I meant.

> >Yes. And you can do this by either using hardware protection, or using a
> >VB interpreter that doesn't let them run off the end of arrays. The
> >JavaVM (other than JNI etc) certainly doesn't need hardware support to
> >keep you from doing something nasty - that's the whole idea of the
> >sandbox.
> 
> What about hardware/software faults?

What about them? You're still going to have the kernel managing the
memory maps in your scheme, and if there's a fault in that software, you
still have a fault. You're still going to have programs like "login"
handling your permissions. It's going to take lots of development to
make it reliable. 

My point was that there are more ways to think about the problem than I
think have been considered. Certainly more solutions than have been
investigated here.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
    Those who work hard with few results always 
           value hard work over getting results.

Re: Progress on AdaOS

[Brian Catlin]

"M. A. Alves" <maa@liacc.up.pt> wrote in message
news:mailman.999279849.27594.comp.lang.ada@ada.eu.org...
> My view is close to that.  ADTs.  File = persistent (un)bounded array of
> storage element (plus user and permission information).  Dir = persistent
> (un)bounded array of files (plus ditto).
>
> But in my dream OS directories would be just one of many ways of grouping
> files.  Other ways: by owner, permission, create time, last update time,
> format...  And a file could really belong to more than one
> directory-category.  An actual forest, which UNIX file system is not (it
> is a tree).
>
> Ultimately it is an identity problem.  UNIX file has key path/filename, so
> directories must form a tree (not a forest).  Dream OS file would have
> another key scheme, perhaps OID (Object Identifier) (= UNIX inode?).

Microsoft's NTFS file system supports the sort of flexibility you're looking
for.  NTFS supports building an index of any file attribute, so a directory is
simply an index built over file names.  Another *really* nice feature, is that a
file can have any number of data streams.  Also, file system meta files (Master
File Table (MFT), bitmap, etc.) are not treated specially; they're just files,
like anything else.  Treating everything orthogonally really simplifies the
implementation.

For more info on NTFS and its capabilities, see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag00/html
/NTFSPart1.asp

 -Brian

Re: Progress on AdaOS

[Keith Thompson]

"M. A. Alves" <maa@liacc.up.pt> writes:
> > If you're building an AdaOS, why not make files that are managed with
> > Ada semantics?
> 
> My view is close to that.  ADTs.  File = persistent (un)bounded array of
> storage element (plus user and permission information).  Dir = persistent
> (un)bounded array of files (plus ditto).
> 
> But in my dream OS directories would be just one of many ways of grouping
> files.  Other ways: by owner, permission, create time, last update time,
> format...  And a file could really belong to more than one
> directory-category.  An actual forest, which UNIX file system is not (it
> is a tree).
> 
> Ultimately it is an identity problem.  UNIX file has key path/filename, so
> directories must form a tree (not a forest).  Dream OS file would have
> another key scheme, perhaps OID (Object Identifier) (= UNIX inode?).

Actually, a UNIX file system isn't necessarily a strict tree.  Two
different directories can contain links to the same file.  (It's
usually kept to a mostly tree-like structure simply to avoid
confusion.)

-- 
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: Progress on AdaOS

[M. A. Alves]

> > Ultimately it is an identity problem.  UNIX file has key path/filename, so
> > directories must form a tree (not a forest).  Dream OS file would have
> > another key scheme, perhaps OID (Object Identifier) (= UNIX inode?).
>
> Actually, a UNIX file system isn't necessarily a strict tree.  Two
> different directories can contain links to the same file.  (It's
> usually kept to a mostly tree-like structure simply to avoid
> confusion.)

Granted.  But still not strictly a forest also: you must have a single
root.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Progress on AdaOS

[David Thompson]

Keith Thompson <kst@cts.com> wrote :
> "M. A. Alves" <maa@liacc.up.pt> writes:
...
> > Ultimately it is an identity problem.  UNIX file has key path/filename, so
> > directories must form a tree (not a forest).  Dream OS file would have
> > another key scheme, perhaps OID (Object Identifier) (= UNIX inode?).
>
> Actually, a UNIX file system isn't necessarily a strict tree.  Two
> different directories can contain links to the same file.  (It's
> usually kept to a mostly tree-like structure simply to avoid
> confusion.)
>
Don't have to be different directories -- common example,
/usr/local/bin/{gzip,gunzip,gzcat} are hardlinks to one file --
but do have to be on the same filesystem = usually partition.

If you (have and) count symbolic links, can have multiple paths
to a directory (or special file) and across filesystems as well.

--
- David.Thompson 1 now at worldnet.att.net

Re: Progress on AdaOS

[M. A. Alves]

On Sun, 9 Sep 2001, David Thompson wrote:

> Keith Thompson <kst@cts.com> wrote :
> > "M. A. Alves" <maa@liacc.up.pt> writes:
> ...
> > > Ultimately it is an identity problem.  UNIX file has key path/filename, so
> > > directories must form a tree (not a forest).  Dream OS file would have
> > > another key scheme, perhaps OID (Object Identifier) (= UNIX inode?).
> >
> > Actually, a UNIX file system isn't necessarily a strict tree.  Two
> > different directories can contain links to the same file.  (It's
> > usually kept to a mostly tree-like structure simply to avoid
> > confusion.)
> >
> Don't have to be different directories -- common example,
> /usr/local/bin/{gzip,gunzip,gzcat} are hardlinks to one file --
> but do have to be on the same filesystem = usually partition.
>
> If you (have and) count symbolic links, can have multiple paths
> to a directory (or special file) and across filesystems as well.

But still not a forest [the original claim], because you must have exactly
one root.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Progress on AdaOS

[David Starner]

On Mon, 10 Sep 2001 10:53:23 +0000 (GMT), M. A. Alves <maa@liacc.up.pt> wrote:
> On Sun, 9 Sep 2001, David Thompson wrote:
> 
>> Keith Thompson <kst@cts.com> wrote :
>> > "M. A. Alves" <maa@liacc.up.pt> writes:
>> ...
>> > > Ultimately it is an identity problem.  UNIX file has key path/filename, so
>> > > directories must form a tree (not a forest).  Dream OS file would have
>> > > another key scheme, perhaps OID (Object Identifier) (= UNIX inode?).
>> >
>> > Actually, a UNIX file system isn't necessarily a strict tree.  Two
>> > different directories can contain links to the same file.  (It's
>> > usually kept to a mostly tree-like structure simply to avoid
>> > confusion.)
> 
> But still not a forest [the original claim], because you must have exactly
> one root.
 
No, the original claim was that it "isn't necessarily a strict tree", 
not that it was a forest.

Why is a problem? I can turn a forest into a tree by adding a base and
links to the base of each subtree; a Unix file system can be viewed as
a forest if you prohibit cd'ing to the root. The difference between
C:\ and /C isn't that much.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS

[M. A. Alves]

> >> > Actually, a UNIX file system isn't necessarily a strict tree.  Two
> >> > different directories can contain links to the same file.  (It's
> >> > usually kept to a mostly tree-like structure simply to avoid
> >> > confusion.)
> >
> > But still not a forest [the original claim], because you must have exactly
> > one root.
>
> No, the original claim was that it "isn't necessarily a strict tree",
> not that it was a forest.
>
> Why is a problem? I can turn a forest into a tree by adding a base and
> links to the base of each subtree; a Unix file system can be viewed as
> a forest if you prohibit cd'ing to the root. The difference between
> C:\ and /C isn't that much.

No problem at all.  'Twas just an academic question.  But the
_really_original_ claim, not reproduced here but I remember it from the
thread 'cause I originated it, was indeed Unix to be a forest.  Of course
you can make a nice forest somewhere _inside_ it, using e.g. your scheme
above, but _it_ is not one.  But anyway no problem, just academic.

 --
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Progress on AdaOS

[Samuel T. Harris]

Darren New wrote:
> 
> 
> How about the type for Ada source files? Ada specification headers? Ada
> bodies? The type for an "Active Server Page" with Ada code embedded in
> HTML markup under control of CVS? And how do you determine which
> programs can read such? :-)

I remember my days of old working on the Rational R1000.
Ada source was an object to the operating system.
To access a unit spec, you used some_unit_name'spec
and to access a unit body you used some_unit_name'body.
One never handled the compilation artifacts, they were
produced when one compiled an Ada unit and remained
"hidden" from view, but still were a "part" of the
Ada object.

So the notion of a file object is somewhat limited.
An OS Object may encompass several raw files.

On the other hand, the notion of forcing everything
into some form of OS Object is too abstract. At some
level raw access to raw files will be required.

And that is as it should be and is, indeed, the Ada way.
Not all Ada programs are OO and not all of them use tagged
types. Some are structurally designed and do very primative
things.

> 
> > So programs
> > like copy can deal with them on the raw data level,
> 
> Only in the most primitive of systems does that work. Does copy *really*
> deal with transfering text files across a TCP link between a unix box
> and a mac box? No, it's the device drivers.

I am in total agreement. A primative file-level copy operation
is completely inadequate for dealing with OS Objects, which
as I have made the case, may encompass many files in several
different locations. To copy such an object, eithere all the
component files are copied to corresponding locations or they
are regenerated in the appropriate manner.


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

Re: Progress on AdaOS

[Ole-Hjalmar Kristensen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Well, in an imaginary OS written in Ada, it would be interesting to develop
> a unique file system as well. One thing to keep in mind is that the file
> system is essentially independent of the core operating system. You could
> build the OS in such a way that it could access Unix, VMS, Windows, Mac,
> and/or its own file system so long as it knew what it was looking at. There
> would be advantages to a file system (like what is on the Mac) that contains
> more than just some raw bytes of data - but you give something up at the
> same time. Its harder to treat files like that as just raw data. (IIRC, the
> advice we once got from DEC on trying to duplicate the "copy" command
> programatically was to not bother trying to do that. It was just too hard to
> account for everything that "copy" had to do to deal with all the variety of
> file types.)
> 
> 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/

The Plan 9 operating system could be a good place to start if you
wanted to get ideas for a novel file system and OS.

> 
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:uBW9YP9YCoMO@eisner.encompasserve.org...
> >
> > Matching the strongly typed tradition of Ada, I think an operating
> > system should have strongly typed files, as discussed in:
> >
> > http://arstechnica.com/reviews/01q3/metadata/metadata-1.html
> >
> > For those who have better things to do that follow links, it discusses
> > file metadata and overloading, and particularly whether the datatype
> > for files is a first class element of metadata or is overloaded onto
> > the filename.  Naturally the datatype of a file is not Integer vs.
> > Float, but something like Photoshop Project File vs. Marin's Rocket
> > Results.
> 
> 

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: Progress on AdaOS

[Marin David Condic]

One thing the world does *not* need is another Unix variant. If the
objective were to reproduce Linux only in Ada, what's the point? Why make
something that has an identical look and feel all the way to its core and
then just be another "me too!" player? Its already been done and redone - go
do something different!

When Chrysler took a look at the big pickup truck market back about '95,
they realized they had less than one percent of it. They were not a serious
player in the market since Ford and Chevy pretty much dominated. That was
the bad news. The good news was that no matter what they did, they could
hardly screw things up worse than they already were. So they decided to get
really radical in their thinking. The result? The Dodge Ram Pickup that has
become a really major success story. So much so that Ford ran off trying to
copy elements of their design, etc., because they lost a really significant
market share to Dodge. (Yes, I happen to own one - ten cylinders & four
wheel drive too! :-)

This led Chrysler to other areas of more radical design thinking - the PT
Cruiser being a good example. It worked because while everyone else was
offering variations on a theme, they had something genuinely *different*
that maybe wasn't going to appeal to *everybody* but certainly was going to
find a large segment of the population that was tired of all the bland
sameness on the market.

In a way, Ada is in an identical position. It has such a small share of the
market that it can't hardly kill itself by getting daring and bold. Offering
something unique and different and bold would be a strategy that - while it
may not kill C/C++, et alia - would certainly have a way of snagging a big
chunk of the market for itself. I'd think that ought to be the strategy for
any big Ada project being done at least in part for purposes of Ada
advocacy.

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@SpamCop.net> wrote in message
news:QzMRgPYPkyBy@eisner.encompasserve.org...
>
> For me, an OS that resembled either Windows or Unix would not be of
> interest.  The only thing that would interest me in an experimental
> operating system is if it had significant new capablities.
>
> Thus Linux wasn't it.  I never saw BeOS or NexT -- perhaps they were it.
>

Re: Progress on AdaOS

[Samuel Tardieu]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
---
>One thing the world does *not* need is another Unix variant. If the
>objective were to reproduce Linux only in Ada, what's the point? Why make
>something that has an identical look and feel all the way to its core and
>then just be another "me too!" player? Its already been done and redone - go
>do something different!

And to quote Chuck Moore, the father of Forth: megabytes OS are not a fatality.

A brand new OS needs not be a giant one.

Re: Progress on AdaOS

[Marin David Condic]

Not sure I get the point..... Need more coffee! :-)

I don't see why an OS available in source code couldn't be made scalable.
You could have some primitive, low level kernel stuff that needn't be huge.
Add onto it all the spiffy things like a file system, a GUI system, an API,
etc., and with some careful planning, I think you could basically build what
you needed.

However, it isn't a crime for an OS to get big. The more functionality you
force down into an OS the less functionality needs to reside in the apps
running on it. Heavy use of graphics and video and all that tends to consume
lots of space - if you want it, buy a bigger disk drive. So long as you can
easily scale the thing to the needs at hand, let it grow to consume as much
space as is available.

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/


"Samuel Tardieu" <sam@rfc1149.net> wrote in message
news:9mekkt$pij$1@melchior.enst.fr...
>
> And to quote Chuck Moore, the father of Forth: megabytes OS are not a
fatality.
>
> A brand new OS needs not be a giant one.

Re: Progress on AdaOS

[Samuel Tardieu]

Marin David Condic wrote:

> However, it isn't a crime for an OS to get big. The more
> functionality you force down into an OS the less functionality
> needs to reside in the apps running on it.

This reasonning quickly leads to code bloat. This is why I do
trust Linux-based systems more than Microsoft ones but less
than BSD ones (BSD developpers usually reject features that are
not deemed as vital, as they can be provided by external
applications which don't need to be part of the OS itself
(the OS in this case being basically the kernel + everything
not in /usr/local or /usr/X11R6).

You need to *trust* your OS. That's why I love when it is
small. If a particular package fails to suit my needs or is
buggy, I just replace it. If a part of the OS fails to suit
my needs or is buggy, either I am stuck with it or it is
unpractical to use a replacement.

Let's take an example: some versions of Solaris ship with
a non-GNU tar; theirs cannot untar files compressed with
gunzip. I need, as almost everyone, to untar .tar.gz files.
My choices are:

   (1) Install GNU tar in /usr/local/bin. One of every two
       times, Murphy's law helping, some utility will use
       /usr/bin/tar when I expect it to use /usr/local/bin/tar.

   (2) Install GNU tar under the name gtar. You have to
       adapt other people scripts that assumed that GNU tar
       was available.

   (3) Install GNU tar over Sun's tar. A system upgrade will
       "unchange" that.

If tar had not been part of the Solaris OS, I could have
installed one of my choices, which suits my needs.

I know those explanations may sound a bit off topic, but
they show why I would prefer a new OS to be minimalist
(who said microkernel-based?) so that I can make a system
that suits my needs on top of it.

   Sam

Re: Progress on AdaOS

[Tony Gair]

Sam,
   you're doing it wrong you should love when its big.

> You need to *trust* your OS. That's why I love when it is
> small. 

Re: Progress on AdaOS

[Samuel Tardieu]

On 29/08, Tony Gair wrote:

|    you're doing it wrong you should love when its big.

When it's too big, it hurts.

Re: Progress on AdaOS

[Richard Riehle]

Samuel Tardieu wrote:

> You need to *trust* your OS. That's why I love when it is
> small. If a particular package fails to suit my needs or is
> buggy, I just replace it. If a part of the OS fails to suit
> my needs or is buggy, either I am stuck with it or it is
> unpractical to use a replacement.

Overheard at Izzy's Bagel Shop on California Avenue in  Palo Alto:

Paraphrased:    "I consider my decision to stop using Microsoft
                          products whenever possible to be an act of
                          patriotism."

There are many reasons why people choose operating systems.   Most
choose Microsoft because it is the path of least resistance not because
it is the best product.  We all know it is not the best product.
However,
few will choose a different operating system unless they have some
passion for doing so.

The person overheard at Izzy's had evidently just completed at purchase
at the nearby Apple dealer across the street.  In his view, Microsoft
has
become the equivalent of an "evil empire" and a danger to the entire
national security, not to mention the economy.   He believes in his
viewpoint
enough to go against the dominant trend.

I am old enough to remember when the phrase, "Nobody ever got fired for
buying IBM," was the near equivalent of revealed truth.  Now, we can
say,
"Nobody ever got fired for choosing Microsoft."    Just as IBM lost its
dominance through a series of hubris-induced blunders, so too Microsoft,

with its arrogance toward the consumers that depend on its products, can

eventually implode unless it someday begins to understand that consumers

want a wider range of choices, more reliable products, and a better
commitment
to service, none of which seem forthcoming in current or projected
Microsoft
product offerings.

An AdaOS, if one is to be developed, needs to focus on a specific
marketplace.
One of Ada's particular strengths is in the real-time and embedded
systems
marketplace.   The language already is a model for consistency and
continuity
that could evolve into a well-formed operating system for that market
segment.
The difficulty will be getting compiler publishers to agree on the
creation of
such a product.    Each Ada compiler publisher prides itself on the
special
qualities of of its RTE, and this is as it should be.    If someone were
to define
a common set of properties for an embedded, concurrent, real-time OS
that
could be written in Ada, support Ada, guarantee efficiency and
reliability,
that OS would not have to compete against Microsoft or Linux or
whatever.

In some ways, I find myself in agreement with the man who claimed he was

doing a patriotic service by abandoning Microsoft products.  I find it
increasingly
scary that our DoD organizations are becoming dependent on this single
source for software.    In fact, Microsoft has now become the one
organization,
among all others, in which there is no need for a competing bid in the
purchase
of software products.    Novell has no voice.   Linux publishers have no
voice.
BeOS, an excellent design, has no voice.   Apple's voice has long ago
been
silenced in most DoD organizations.   Perhaps the man in Izzy's was
right.
Perhaps a decision to dump Microsoft products in favor of some equally
effective alternative really is an act of patriotism.   I found his
comment
intriguing, even if it is a bit unrealistic in our current technological
climate.

Perhaps there is a place for an AdaOS.

Richard Riehle
richard@adaworks.com

Re: Progress on AdaOS

[Larry Kilgallen]

In article <3B8AB6C8.910130C8@san.rr.com>, Darren New <dnew@san.rr.com> writes:

>> Then we have
>> for example, types text, image, video, audio, program, data and
>> text/utf8, text/utf8/crlf, text/utf8/lf, text/utf8/psls, image/png,
>> image/tiff, image/tiff/lzw, data/word, data/word/7.0, etc. 
> 
> How about the type for Ada source files? Ada specification headers? Ada
> bodies? The type for an "Active Server Page" with Ada code embedded in
> HTML markup under control of CVS? And how do you determine which
> programs can read such? :-)

You determine which programs can read it by having the programs declare
that they can read it.  A user must be able to choose their "preferred"
reader for a particular type, if there are multiple possible readers.
But there are various types of "reading" there is the "edit" type and
the "compile" type for source files, but for object files there is
the "link" type and the "strip out symbol data" type.

>> So programs
>> like copy can deal with them on the raw data level,
> 
> Only in the most primitive of systems does that work. Does copy *really*
> deal with transfering text files across a TCP link between a unix box
> and a mac box? No, it's the device drivers.

On a VMS system the device driver has absolutely nothing to do with
copying files across a TCP link.  The interface between the user mode
program and the device driver is the socket interface (in the case of TCP).

Re: Progress on AdaOS

[Steffen Huber]

Larry Kilgallen wrote:
> 
> In article <3B8AB6C8.910130C8@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> 
> >> Then we have
> >> for example, types text, image, video, audio, program, data and
> >> text/utf8, text/utf8/crlf, text/utf8/lf, text/utf8/psls, image/png,
> >> image/tiff, image/tiff/lzw, data/word, data/word/7.0, etc.
> >
> > How about the type for Ada source files? Ada specification headers? Ada
> > bodies? The type for an "Active Server Page" with Ada code embedded in
> > HTML markup under control of CVS? And how do you determine which
> > programs can read such? :-)
> 
> You determine which programs can read it by having the programs declare
> that they can read it.

You have just described the RISC OS way of handling the problem.
Congratulations ;-)

> A user must be able to choose their "preferred"
> reader for a particular type, if there are multiple possible readers.

RISC OS does that in an interesting, and sometimes strange (for the
user) way.

RISC OS defines a "filetype" for types of file contents. This filetype
is allocated centrally and must be unique for every type of content.
There are a few things connected to the filetype like a translation
table to MimeMaps and to DOS extensions for outside communication (this
was an afterthought of course).

Every RISC OS application is "hidden" inside a special directory on
the filing system. As soon as the application is "seen" by the system
(which happens when the user opens the filer window (RISC OS equivalent
to the Windows Explorer) where the application happens to be), a batch
file inside the application (named !Boot) is executed. If the application
is able to handle a special filetype, it declares that it can handle
that filetype. If another application is "seen" by the system that
handles that filetype, the first declaration gets overwritten. So basically
the user decides by using the respective part of the filing system which
application he prefers to handle his data.

Apart from that, due to RISC OS's way of implementing drag&drop,
double clicks are not overly important.

> But there are various types of "reading" there is the "edit" type and
> the "compile" type for source files, but for object files there is
> the "link" type and the "strip out symbol data" type.

This is not handled by RISC OS in any meaningful way - well, RISC OS
was created in 1987, so you can't really expect perfection ;-)

[snip]

ObAda: there is a port of GNAT 3.03 for RISC OS...

Steffen

-- 
steffen.huber@gmx.de               steffen@huber-net.de
GCC for RISC OS  - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[David Starner]

On Tue, 21 Aug 2001 11:29:11 -0400, Marin David Condic wrote:
>  However, if there
> was some carrot held out in the way of a future reward, maybe some people
> would see it as an opportunity to make a few $$$ on the side and devote more
> time to it. Putting the OS out under the GPL (or some version thereof) might
> not hold out much hope of money. If it was being developed under some more
> "restrictive" license such that the developers might be able to make some
> $$$ from eventual sales, 

What niche are targetting with this OS? If you're targetting anywhere
around the desktop/server area:

Linux: $0 (CD's in the $2-$10 range, boxes in the $20-$100 range)
*BSD: $0 (CD's in the $2-$30 range)
BeOS: $0 (boxes in the $100 area)
MacOS X: $0 (with computer) (boxes in the $100 range)
Windows##: $0 (with computer) (boxes in the $100-$200 range)
Windows NT: $100s 

Considering that 5 out of the 6 are in the $0 range for most people, 
and 2 out of the 6 have no use or distribution restrictions*,
that Linux will be bigger, badder and still free when you get AdaOS done,
and Windows NT's big selling points are amount of software and full Windows
compatibility, I think moving into this niche with a non-$0 price-tag is
a sure sign of failure. 

* Excluding a few distributions, and talking in a practical sense for
an end user or company.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Marin David Condic]

First off, lets clarify a couple of things. I am not involved with AdaOS and
am not in any way shape or form looking to be involved with AdaOS. Hence I'm
not targeting anything for any market. What I am observing is that AdaOS is
Vaporware and one of the reasons is that (IMHO) nobody is getting paid or
seeing some way of eventually getting paid for having been involved in
developing it. My contention is that the closer the connection is between
doing some work and seeing some money from it, the more likely you are to
see the work getting done. This is just basic human psychology - ask any
first-year psych student.

Second off, you are not correct in stating that MacOS and Windows## are $0
in cost. When you buy a computer that has this already installed the cost of
the OS is simply part of the cost of the computer. Do you believe it when a
car dealer tells you "I'm throwing in the bucket seats and spoiler trim
package free!" Of course he isn't. Whatever it costs him to have those
bucket seats and trim packages installed is going to be figured into the
profit margin he needs on the sale of the car in order to stay in business.
Same goes for the computer manufacturer who installs Windows for you.

Now as to how somebody (not me!) is going to make money on AdaOS? Your guess
is as good as mine. Maybe like Act, Cygnus, Red Hat, et alia, they end up
making something by selling support & training. Will that be the guys who
are writing the OS? (If in fact anybody is writing anything) Again, your
guess is as good as mine. Will they be able to sell a CD with AdaOS on it
for $29.95? Maybe. Who knows? Its their problem. My observation remains the
same: If nobody is seeing any financial rewards for working on it, the
chances that it gets completed are going to diminish.

When Bill Gates woke up one day and said "I think I'm gonna build me an OS!"
and threw a few million at the development of WinNT, he eventually got
himself an OS - more or less according to plan and on schedule. What do you
suppose the odds are that if I post here "Will somebody go write me an OS in
Ada - just because I want one - and no, I don't have any money to give you
when you deliver it to me." that I'll get one while holding my breath? :-)

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" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9lujcr$aai2@news.cis.okstate.edu...
>
> What niche are targetting with this OS? If you're targetting anywhere
> around the desktop/server area:
>
> Linux: $0 (CD's in the $2-$10 range, boxes in the $20-$100 range)
> *BSD: $0 (CD's in the $2-$30 range)
> BeOS: $0 (boxes in the $100 area)
> MacOS X: $0 (with computer) (boxes in the $100 range)
> Windows##: $0 (with computer) (boxes in the $100-$200 range)
> Windows NT: $100s
>
> Considering that 5 out of the 6 are in the $0 range for most people,
> and 2 out of the 6 have no use or distribution restrictions*,
> that Linux will be bigger, badder and still free when you get AdaOS done,
> and Windows NT's big selling points are amount of software and full
Windows
> compatibility, I think moving into this niche with a non-$0 price-tag is
> a sure sign of failure.
>
> * Excluding a few distributions, and talking in a practical sense for
> an end user or company.
>

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Ted Dennison]

In article <9m0e48$5he$1@nh.pace.co.uk>, Marin David Condic says...
>
>First off, lets clarify a couple of things. I am not involved with AdaOS and
>am not in any way shape or form looking to be involved with AdaOS. Hence I'm
>not targeting anything for any market. What I am observing is that AdaOS is
>Vaporware and one of the reasons is that (IMHO) nobody is getting paid or
>seeing some way of eventually getting paid for having been involved in

That is indeed one reason. However, you can't make the argument that its failing
because of its status as an OpenSource project, because:

a) There are plenty of other succesful counter-examples.
b) It has never been organized the way any of those other succesful
counter-examples were organized.

OpenSource projects, if performed properly, *do* have their own system of
rewards for the participants. If you have some spare time, I'd suggest you read
over ESR's essay "Homesteading the Noosphere". It goes into this in great
detail. As it was written by a raving libertarinan, it couched entirely in
market and reward/punishment terms. I suspect you would be more receptive to
that than the FSF's ideology. :-)

My stupid net-nanny won't let me see it anymore, but I believe its up at
http://www.tuxedo.org/~esr/writings/ somewhere.

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

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Preben Randhol]

On Wed, 22 Aug 2001 16:42:06 GMT, Ted Dennison wrote:
> My stupid net-nanny won't let me see it anymore, but I believe its up at
> http://www.tuxedo.org/~esr/writings/ somewhere.

What kind of net-nanny is this? To protection one from free speech?

Preben Randhol
-- 
�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: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Marin David Condic]

O.K. I don't recall saying that it was doomed because it was Open Source. I
think I may have said elsewhere that I could envision a scheme whereby an OS
might still make lots of money for the developers even if it *were* open
source. I think I can see a number of applications where the open source
type of GPL deal might work very well to the advantage of the authors of the
product. In other cases, I would think that the Open Source/GPL type of
thing would hurt the authors of the work. What the *authors* decide to do
about that is ultimately their own business. I'm merely suggesting that if
the project is not organized in some manner to provide an incentive bigger
than a warm-fuzzy feeling, it isn't as likely to achieve its stated goals.
If that means that Open Source is the enemy, then there you have it. I don't
think this is the case for an OS - but it might be for other kinds of
products.

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:yhRg7.10738$2u.76684@www.newsranger.com...
>
> That is indeed one reason. However, you can't make the argument that its
failing
> because of its status as an OpenSource project, because:
>
> a) There are plenty of other succesful counter-examples.
> b) It has never been organized the way any of those other succesful
> counter-examples were organized.
>
> OpenSource projects, if performed properly, *do* have their own system of
> rewards for the participants. If you have some spare time, I'd suggest you
read
> over ESR's essay "Homesteading the Noosphere". It goes into this in great
> detail. As it was written by a raving libertarinan, it couched entirely in
> market and reward/punishment terms. I suspect you would be more receptive
to
> that than the FSF's ideology. :-)
>
> My stupid net-nanny won't let me see it anymore, but I believe its up at
> http://www.tuxedo.org/~esr/writings/ somewhere.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Steinar Knutsen]

In article <yhRg7.10738$2u.76684@www.newsranger.com>, Ted Dennison
<dennison@telepath.com> wrote:

>In article <9m0e48$5he$1@nh.pace.co.uk>, Marin David Condic says...
>
>>[...] What I am observing is that AdaOS is Vaporware and one of the
>>reasons is that (IMHO) nobody is getting paid or seeing some way of
>>eventually getting paid for having been involved in
>
>That is indeed one reason. However, you can't make the argument that
>its failing because of its status as an OpenSource project, because:
>
>a) There are plenty of other succesful counter-examples. b) It
>has never been organized the way any of those other succesful
>counter-examples were organized.
>
>OpenSource projects, if performed properly, *do* have their own system
>of rewards for the participants. If you have some spare time, I'd
>suggest you read over ESR's essay "Homesteading the Noosphere". [...]

Another interesting text is (chosen more or less at random from a huge
pile on the subject)
http://www.zigonperf.com/PMNews/reward_and_perf_research.html

Quote from findings from this study: "Findings from the meta-analysis
indicate that only expected tangible rewards had a decremental effect on
performance."

Search for "overjustification" and some other appropriate keywords on
Google or your search engine of choice and loads of papers and articles
and lecture notes will pop up.

Cut'n'paste: The "Overjustification" Hypothesis:  A person's intrinsic
interest in an activity may be decreased by inducing them to engage in
the activity as an explicit means to some extrinsic goal.

Sounds reasonable to me, any student knows that no matter how
interesting a subject is, it will become a boring headache when it
enters a curriculum. ;)
-- 
Steinar

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[David Starner]

On Wed, 22 Aug 2001 10:03:48 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> My contention is that the closer the connection is between
> doing some work and seeing some money from it, the more likely you are to
> see the work getting done. This is just basic human psychology - ask any
> first-year psych student.

See "Studies Find Reward Often No Motivator", from the Boston Globe
<http://www.gnu.org/philosophy/motivation.html>. 
 
> Second off, you are not correct in stating that MacOS and Windows## are $0
> in cost. When you buy a computer that has this already installed the cost of
> the OS is simply part of the cost of the computer.

I knew someone would say this. The point is, it's hard to get a home computer
without MacOS or Windows## on it. If I buy a computer (which comes with
Windows), I pay $N. If I buy a computer and then buy AdaOS and remove
what ever came with the computer, it costs $N + $A. So, effictively, Windows
cost me $N - $N = $0.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Warren W. Gay VE3WWG]

David Starner wrote:
> On Wed, 22 Aug 2001 10:03:48 -0400, Marin David Condic > > Second off, you are not correct in stating that MacOS and Windows## are $0
> > in cost. When you buy a computer that has this already installed the cost of
> > the OS is simply part of the cost of the computer.
> 
> I knew someone would say this. The point is, it's hard to get a home computer
> without MacOS or Windows## on it. If I buy a computer (which comes with
> Windows), I pay $N. If I buy a computer and then buy AdaOS and remove
> what ever came with the computer, it costs $N + $A. So, effictively, Windows
> cost me $N - $N = $0.

When I bought my last PC, I told them "I didn't need Windows" (I was
planning on using it for Linux/FreeBSD). I saved ~ $120 that way. 
Sure, they probably installed Windows to test all the
components, but then it was removed before I got the machine.

You're right, it is sometimes "hard", but as a customer, you have to
state your requirements. ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[David Starner]

On Tue, 21 Aug 2001 15:05:00 GMT, Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> Just to correct an earlier post : *BSD is the real _UNIX_ from years ago.
> It just took a while to have ports of it made available to the PC platform,
> but it is the real UNIX; while Linux is the UNIX-like O/S. The first
> socket implementation for TCP/IP was on BSD UNIX, for example.

BSD is _not_ the real UNIX(tm), as the makers of BSD/OS found out when they
got sued for calling BSD/OS UNIX. Parts of BSD may have ended up in UNIX(tm)
and older versions of BSD may have been UNIX(tm), but every part of BSD that
was UNIX(tm) was removed and rewritten for the free releases. To the best of
my knowledge, no *BSD has ever been run through the (expensive) tests for
UNIX(tm) certification.
 
In any real sense, as opposed to a legal sense, I don't see why *BSD is any
more or less UNIX than Linux. Neither of them have real UNIX code, and both
mostly obey the Unix standards. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red

[Warren W. Gay VE3WWG]

David Starner wrote:
> On Tue, 21 Aug 2001 15:05:00 GMT, Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> > Just to correct an earlier post : *BSD is the real _UNIX_ from years ago.
> > It just took a while to have ports of it made available to the PC platform,
> > but it is the real UNIX; while Linux is the UNIX-like O/S. The first
> > socket implementation for TCP/IP was on BSD UNIX, for example.
> 
> BSD is _not_ the real UNIX(tm), as the makers of BSD/OS found out when they
> got sued for calling BSD/OS UNIX. Parts of BSD may have ended up in UNIX(tm)
> and older versions of BSD may have been UNIX(tm), but every part of BSD that
> was UNIX(tm) was removed and rewritten for the free releases. To the best of
> my knowledge, no *BSD has ever been run through the (expensive) tests for
> UNIX(tm) certification.

I did completely ignore the UNIX trademark issue, and will continue to 
sidestep that here... but..

The *BSD variants of today, still have some of the original
AT&T UNIX code in them, AFAIK. The first release of BSD was derived 
from AT&T UNIX Sixth Edition (V6). See 

	http://www.unix-wizards.com/tree.html 

for a picture of the family tree. Note that FreeBSD derives from 
386BSD 0.0, which derives from 4.3BSD NET/2, whose grandaddy is 
Sixth Edition (V6).

> In any real sense, as opposed to a legal sense, I don't see why *BSD is any
> more or less UNIX than Linux. Neither of them have real UNIX code, and both
> mostly obey the Unix standards.

I know what you're saying. But if you were a Hatfield, and your grandaddy
was a Hatfield, you wouldn't want some McCoy coming along claiming to
be a Hatfield ;-)  Those would be "fighten words", as it often is when
Linux enthusiasts are reminded of this.

For further clarifications on this, I suggest a visit to www.freebsd.org.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: OT: Progress on AdaOS

[David Starner]

On Wed, 22 Aug 2001 01:50:33 GMT, Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> The *BSD variants of today, still have some of the original
> AT&T UNIX code in them, AFAIK. The first release of BSD was derived 
> from AT&T UNIX Sixth Edition (V6). 

Yes, the first release of BSD was derived from AT&T Unix. But when it
was released publically (4.3BSD NET/2), all the AT&T Unix code (all
labeled unpublished and proprietory) was removed - they didn't have a 
right to distribute it. Latter, AT&T sued Berkeley and forced them to
remove another half a dozen files; to prevent being sued, all the *BSD
moved from 4.3BSD NET/2 to the certified AT&T clean 4.4BSD-lite.

> I know what you're saying. But if you were a Hatfield, and your grandaddy
> was a Hatfield, you wouldn't want some McCoy coming along claiming to
> be a Hatfield ;-)  Those would be "fighten words", as it often is when
> Linux enthusiasts are reminded of this.

It's a one sided war; not many of Linux people bear any animosity 
towards *BSD. Frankly, the whole UNIX issue is not a big deal to me;
I just see no reason why with two systems that look so much alike and are
both so much alike UNIX systems, one should be considered UNIX and the
other not.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.)

[Darren New]

Jeffrey Carter wrote:
> While
> the result was a very useful free compiler, it is instructive to note
> that GNU never created an OS.

Sure they did. They called it Emacs. ;-)

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
           When was sliced bread invented?

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

[Ted Dennison]

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

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

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

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

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

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

[Adam Fineman]

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

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

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

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

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

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

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

[Ted Dennison]

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

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

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

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

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

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

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

[Adam Fineman]

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

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

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

<snip>

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

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

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

[Gary Scott]

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

http://www.ccur.com

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

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

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

[Adam Fineman]

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

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

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

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

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

[Markus Mottl]

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

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

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

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

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

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

Regards,
Markus Mottl

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

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

[Adam Fineman]

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

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

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

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

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

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

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

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

- Adam

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

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

[Tore Lund]

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

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

QNX (was Re: How Ada could have prevented ...)

[Ray Blaak]

Tore Lund <tl001@online.no> writes:
> QNX is real-time, off-the-shelf and general-purpose, as well as
> POSIX-compliant.  (At least according to QNX blurb.)  Has anyone
> considered QNX for use on warships...?

It doesn't have an Ada compiler for it, as far as I know, although I do recall
some people asking on comp.lang.ada if GNAT has been ported to it.

It certainly is a wonderfully *neat* OS. I would love to work with it, myself.

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

[Ted Dennison]

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

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

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

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

[Markus Mottl]

In comp.lang.functional 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

OT: US global politics (was: How Ada could have prevented the Red Code distributed denial of service attack.)

[Ted Dennison]

In article <9m14np$rcs$1@bird.wu-wien.ac.at>, Markus Mottl says...
>
>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...

Yes, it does indeed look that way. But you have to realise that our president
can only really shoot his mouth off (ticking off friends in the process). All
treaty decisions have to be made by our Congress, which didn't really change all
that much since the last election.

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

Re: OT: US global politics

[Markus Mottl]

In comp.lang.functional Ted Dennison <dennison@telepath.com> wrote:
> Yes, it does indeed look that way. But you have to realise that our
> president can only really shoot his mouth off (ticking off friends in
> the process). All treaty decisions have to be made by our Congress,
> which didn't really change all that much since the last election.

So there is still hope...

Furthermore, I also hope that the US "update" their election process
and that US citizens choose wisely during the next elections.

Anyway, we are already greatly off topic now...

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

[Ted Dennison]

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

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


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

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

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

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

[Richard Riehle]

Ted Dennison wrote:

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

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

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

Richard Riehle

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

[tmoran]

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

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

[Garry Hodgson]

Ted Dennison wrote:

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

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

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

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

[Samuel T. Harris]

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

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

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


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

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

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

Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Warren W. Gay VE3WWG]

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

IMHO, it seems to me that advantages of having compiler generated 
bounds checking and overflow checking code are too often 
dismissed by the C/C++ camp.

Just the other day, I came across a subtle C problem, that was
discovered when I ported the algorthm to Ada95. I checked the 
most recent version of SoX source, and the problem _still_
exists there, apparently still undiscovered.

Ada on the other hand, detected the problem very early 
in the porting development.

The following C snippet converts linear 16-bit 
signed sound samples to A-law compressed samples. The 
abbreviated code looks like this:

#define ACLIP 31744
...
unsigned char
st_linear_to_Alaw( sample )
short sample;
    {
    static const unsigned char exp_lut[128] = { ...snip... };
    int sign, exponent, mantissa;
    unsigned char Alawbyte;

    /* Get the sample into sign-magnitude. */
    sign = ((~sample) >> 8) & 0x80;		/* set aside the sign */
    if ( sign == 0 ) sample = -sample;		/* get magnitude */
    if ( sample > ACLIP ) sample = ACLIP;	/* clip the magnitude */
    ...

The logic is a bit twisted here because of the way the
sign bit is tested, but you should be able to see the
problem with a bit of effort.

The error occurs on the following line :

    if ( sign == 0 ) sample = -sample;		/* get magnitude */

Did anybody spot the problem?  I'm sure some did,
since I drew attentiont to it. While the logic is 
reversed in "(sign == 0)", the problem is this:

The statement sample = -sample is executed when the linear 
sample is negative, and _then_ the sample is clipped 
based on its _positive_ magnitude, in the next statement.

But what happens when the sample is -32768 ?

Testing this on Red Hat 7, under Linux and HPUX, the 
result of the test shows that sample = -sample when 
sample = -32768 is -32768 !  With this as the result, 
the next statement fails to carry out the clipping 
code: sample = ACLIP;

The end result?  A botched encoded sample. Something that
you probably would not hear with your ear. In practice
this only happens when your samples are maxing out on
the 16-bit range, which for recordings will likely result
in a lot of clipped (noisy) samples anyway.

So you might say, "so what?"

Two things:

1) The result is incorrect (that should be enough)

2) This is still a problem for good 16-bit samples 
   that are perhaps "processed" to use the maximum 
   dynamic range (they may have been 32-bit samples 
   before processed into 16-bit samples).

Ada picked this problem up right away, albeit at runtime.
When I saw the constraint error there, I immediately 
realized that I had overlooked this special case. This 
long time problem was obviously never detected by 
the C developers, and may now eventually get fixed 
as a result of this posting ;-)

I wonder how many other sound projects derived from this
same code, and possess the same bug? Windows CoolEdit?

Anyway, while sound samples don't paralyze ships, I felt 
that this is another example of how subtle errors like this
can go undetected in C/C++ code.  Ada on the other hand
was quick to point out this flaw. Kudos to GNAT. ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Ted Dennison]

In article <3B83F042.4CFB073D@home.com>, Warren W. Gay VE3WWG says...
>IMHO, it seems to me that advantages of having compiler generated 
>bounds checking and overflow checking code are too often 
>dismissed by the C/C++ camp.

Its a lot easier to dismiss, when you've never tasted its charms in the first
place. :-)

>Just the other day, I came across a subtle C problem, that was
>discovered when I ported the algorthm to Ada95. I checked the 
>most recent version of SoX source, and the problem _still_
>exists there, apparently still undiscovered.

Its truly *amazing* how many times I've heard that exact same story (although
the other language is not always C). I've even heard one person seriously
suggest that an Ada port may be a good idea for projects that have no intention
of using the Ada port, just to catch some more bugs. I think that's probably a
bit extreme though. :-)

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

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Warren W. Gay VE3WWG]

Ted Dennison wrote:
> >Just the other day, I came across a subtle C problem, that was
> >discovered when I ported the algorthm to Ada95. I checked the
> >most recent version of SoX source, and the problem _still_
> >exists there, apparently still undiscovered.
> 
> Its truly *amazing* how many times I've heard that exact same story (although
> the other language is not always C). I've even heard one person seriously
> suggest that an Ada port may be a good idea for projects that have no intention
> of using the Ada port, just to catch some more bugs. I think that's probably a
> bit extreme though. :-)

Heh heh, an interesting idea ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[David Starner]

On Wed, 22 Aug 2001 18:55:46 GMT, Ted Dennison <dennison@telepath.com> wrote:
> Its truly *amazing* how many times I've heard that exact same story (although
> the other language is not always C). 

It's interesting that the C++ bug that got me to try Ada wouldn't have 
been fixed by Ada - I was trying to deallocate an item on the stack. But
I never would have made it in Ada; I never would have been messing with 
pointers in the first place, and I never would have mixed up getting a
pointer to an item with dereferencing an item in Ada.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Kaz Kylheku]

In article <3B83F042.4CFB073D@home.com>, Warren W. Gay VE3WWG wrote:
>#define ACLIP 31744
>...
>unsigned char
>st_linear_to_Alaw( sample )
>short sample;
>    {
>    static const unsigned char exp_lut[128] = { ...snip... };
>    int sign, exponent, mantissa;
>    unsigned char Alawbyte;
>
>    /* Get the sample into sign-magnitude. */
>    sign = ((~sample) >> 8) & 0x80;		/* set aside the sign */
>    if ( sign == 0 ) sample = -sample;		/* get magnitude */
>    if ( sample > ACLIP ) sample = ACLIP;	/* clip the magnitude */
>    ...

Even before seeing the body of the function, I wonder why it's using
old-style C. Even if there is a good reason for using old-style C,
why is it using a promotable type for a parameter? The use of a promotable
type means that if a correct function prototype is written for the
function, it will have to use the promoted type, that is to say:

	unsigned char st_linear_to_Alaw (int sample);

Lastly, why is the type short being used at all? The advantage of short
is that it may provide a compact representation for a large array of
integers, provided that a range no wider than -32767 to 32767 is required
(the minimum range required by ANSI/ISO C for the type short).

The way the sign is detected is completely braindamaged; it assumes
that signed short is 16 bits wide, so that shifting it 8 bits
to the right will cause the sign bit to land in position 7.
Also, shifting right a signed quantity whose sign bit is 1 is
implementation-defined; I think it's undefined in C99.

What is wrong with, say:

	sign = (sample >= 0);	/* 0 if negative */

Clearly, the programmer did not inspect that the function will produce
the correct output value for every input.  It was obviously not even
tested or inspected what happens in inputs representing interesting
partitions of the input space, such as -32768, -32767, 0 or 32767.

The program is probably not accompanied by test cases consisting of files
containing 16 bit linear samples and corresponding alaw files that are
known to be correct.

So we could say a number of things besides ``sox is written in the
wrong programming language''.

If this function is submitted for critique to comp.lang.c, the errors
in it will be shaken out in an instant, and a maximally portable version
will soon appear that will work on C implementations with unusual sizes
of integral types, CHAR_BIT other than 8, and sign-magnitude or ones'
complement representations for negative numbers. Try it!

Would you hire the programmer who wrote this function, to work with you
on a project in *any* programming language? 

If we are going to blame the programming language rather than the
programmer then let's do it right. If the programming language is at
fault, then it's because of the data representation. The program logic is
correct over abstract integers; it fails due to the machine-oriented data
represetation.   So the problem is that the language allows the programmer
to say ``use ony 16 bits and fail if the computation requires more''.
That in itself is an usafe feature, regardless of whether the overflow
is detected or not. Either way, the program fails to compute the result.

Although detection in Ada is superior to ignoring the error in C,
stopping the program on 16 bit overflow can still crash a rocket.

If I ported the essence of the algorithm to Common Lisp (for instance),
then it will just work. The additive inverse of  -32768 will be happily
computed as 32768.  The undisciplined programmer won't be seduced into
writing nonsense, such as artificially restricting the width of the
computation. The integer type tries to approximate mathematical integers
within the limitations of the machine resources.

(defconstant *alaw-clip* 42) ;; substitute actual value here

(defun st-linear-to-alaw (sample)
 (check-type sample integer)
 (let ((is-negative (< sample 0)))
  (setf sample (min (abs sample) *alaw-clip*))

   ;; rest of the algorithm with a-law table lookup, etc...

   ))

No bit manipulation tricks for detecting the sign, no 16 bit
representation braindamage. The sample parameter could be a bignum,
and it will work correctly. An alorithm can be described using pure,
mathematical integers, and then turned into code directly, without
worring about representation issues such as the limited range of
integers. Prevention of such issues is superior to detection.

So the bottom line is that whether you are programming in static
languages like C or Ada, you are metaphorically carving clay tablets
with with stone knives.  These languages trade reliability and clarity
for machine efficiency. Trivial differences among them are dwarfed by
the differences between them and a truly high level language.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Dale Stanbrough]

Kaz Kylheku wrote:

> Even before seeing the body of the function, I wonder why it's using
> old-style C. Even if there is a good reason for using old-style C,
> why is it using a promotable type for a parameter? The use of a promotable
> type means that if a correct function prototype is written for the
> function, it will have to use the promoted type, that is to say:
> 
> 	unsigned char st_linear_to_Alaw (int sample);
> 
> Lastly, why is the type short being used at all? The advantage of short
> is that it may provide a compact representation for a large array of
> integers, provided that a range no wider than -32767 to 32767 is required
> (the minimum range required by ANSI/ISO C for the type short).
> 
[...]


So we can say in summary that Ada helps when people make mistakes?

Dale

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Kaz Kylheku wrote:
> 
> In article <3B83F042.4CFB073D@home.com>, Warren W. Gay VE3WWG wrote:
> >#define ACLIP 31744
> >...
> >unsigned char
> >st_linear_to_Alaw( sample )
> >short sample;
> >    {
> >    static const unsigned char exp_lut[128] = { ...snip... };
> >    int sign, exponent, mantissa;
> >    unsigned char Alawbyte;
> >
> >    /* Get the sample into sign-magnitude. */
> >    sign = ((~sample) >> 8) & 0x80;            /* set aside the sign */

[...]

> The way the sign is detected is completely braindamaged; it assumes
> that signed short is 16 bits wide, so that shifting it 8 bits
> to the right will cause the sign bit to land in position 7.

It's even more brain damaged than that. It assumes that /int/ is 16
bits.

> Also, shifting right a signed quantity whose sign bit is 1 is
> implementation-defined;

This doesn't matter in this case. The value that the vacated bits take
is indeed implementation defined, but the sign bit must reliably be
shifted into the required position, since nothing frees it from the
requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
positions".

> I think it's undefined in C99.

No, it isn't.

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Igor Tandetnik]

"Joe Maun" <reply_to@yahoo.com> wrote in message
news:3B8462C8.5596C089@yahoo.com...
> Kaz Kylheku wrote:
> > Also, shifting right a signed quantity whose sign bit is 1 is
> > implementation-defined;
>
> This doesn't matter in this case. The value that the vacated bits take
> is indeed implementation defined, but the sign bit must reliably be
> shifted into the required position, since nothing frees it from the
> requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
> positions".
>
> > I think it's undefined in C99.
>
> No, it isn't.
>
> --
> Joe Maun
> Montreal, QC
> Canada

I don't know. C99 says: "If E1 has a signed type and a negative value, the
resulting value is implementation-defined." It says the whole result of the
shift is implementation-defined, not that the bits to the left of original
bits are implementation-defined. I don't see any guarantee that original
bits have to be preserved.

C++ standard has the same exact wording.
--
With best wishes,
    Igor Tandetnik

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[pete]

Igor Tandetnik wrote:
> 
> "Joe Maun" <reply_to@yahoo.com> wrote in message
> news:3B8462C8.5596C089@yahoo.com...
> > Kaz Kylheku wrote:
> > > Also, shifting right a signed quantity whose sign bit is 1 is
> > > implementation-defined;
> >
> > This doesn't matter in this case. The value that the vacated bits take
> > is indeed implementation defined, but the sign bit must reliably be
> > shifted into the required position, since nothing frees it from the
> > requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
> > positions".
> >
> > > I think it's undefined in C99.
> >
> > No, it isn't.

> 
> I don't know. C99 says: 
> "If E1 has a signed type and a negative value, 
> the resulting value is implementation-defined."
> It says the whole result of the shift is implementation-defined, 
> not that the bits to the left of original bits are 
> implementation-defined. I don't see any guarantee that original
> bits have to be preserved.

> C++ standard has the same exact wording.

The propagation of the high order bit when a signed integer
is shifted right is THE example of implementation-defined behavior.

-- 
 pete

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Igor Tandetnik]

"pete" <pfiland@mindspring.com> wrote in message
news:3B888631.204F@mindspring.com...
> Igor Tandetnik wrote:
> >
> > "Joe Maun" <reply_to@yahoo.com> wrote in message
> > news:3B8462C8.5596C089@yahoo.com...
> > > Kaz Kylheku wrote:
> > > > Also, shifting right a signed quantity whose sign bit is 1 is
> > > > implementation-defined;
> > >
> > > This doesn't matter in this case. The value that the vacated bits take
> > > is indeed implementation defined, but the sign bit must reliably be
> > > shifted into the required position, since nothing frees it from the
> > > requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
> > > positions".
> > >
> > > > I think it's undefined in C99.
> > >
> > > No, it isn't.
>
> >
> > I don't know. C99 says:
> > "If E1 has a signed type and a negative value,
> > the resulting value is implementation-defined."
> > It says the whole result of the shift is implementation-defined,
> > not that the bits to the left of original bits are
> > implementation-defined. I don't see any guarantee that original
> > bits have to be preserved.
>
> > C++ standard has the same exact wording.
>
> The propagation of the high order bit when a signed integer
> is shifted right is THE example of implementation-defined behavior.

The question is not what happens to high-order bits that are introduced by
the shift - it is clear that the standards make no guarantee about it and
leave it to implementation. The question is what happens to the bits that
were there before the shift - do the standards guarantee that all of the
original bits (except low-order ones shifted away) are preserved albeit
shifted from their original positions?

Joe Maun says that one can reliably examine the sign bit even after it was
shifted from its original leftmost position. I argue that the standards
specify that all the bits of the result of the shift operation are
implementation-defined - not just high-order bits that the shift introduces.
--
With best wishes,
    Igor Tandetnik

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Igor Tandetnik wrote:
> 
> Joe Maun says that one can reliably examine the sign bit even after it was
> shifted from its original leftmost position. I argue that the standards
> specify that all the bits of the result of the shift operation are
> implementation-defined - not just high-order bits that the shift introduces.

The standards say that the *value* resulting from the expression is
implementation-defined. They also say that the result is "E1
right-shifted E2 bit positions". Since these two statements are not
contradictory (not specifying the high order bits is sufficient to make
the /value/ implementation defined), why do you think the latter doesn't
apply?

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Igor Tandetnik]

"Joe Maun" <reply_to@yahoo.com> wrote in message
news:3B89A7D4.6E7A8BC4@yahoo.com...
> Igor Tandetnik wrote:
> >
> > Joe Maun says that one can reliably examine the sign bit even after it
was
> > shifted from its original leftmost position. I argue that the standards
> > specify that all the bits of the result of the shift operation are
> > implementation-defined - not just high-order bits that the shift
introduces.
>
> The standards say that the *value* resulting from the expression is
> implementation-defined. They also say that the result is "E1
> right-shifted E2 bit positions". Since these two statements are not
> contradictory (not specifying the high order bits is sufficient to make
> the /value/ implementation defined), why do you think the latter doesn't
> apply?

On one hand, I can see how the standard can be read your way. On the other
hand, I can't say that this clause in the standard is absolutely clear and
unambiguous. My opinion is that those two statements can be considered
contradictory, and, just to be on the safe side, I would not recommend
relying on the result of righ-shifting a negative value in a code intended
to be portable.
--
With best wishes,
    Igor Tandetnik

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Kaz Kylheku]

In article <tc8i7.54354$l7.6548595@typhoon.nyc.rr.com>, Igor Tandetnik wrote:
>
>The question is not what happens to high-order bits that are introduced by
>the shift - it is clear that the standards make no guarantee about it and
>leave it to implementation. The question is what happens to the bits that
>were there before the shift - do the standards guarantee that all of the
>original bits (except low-order ones shifted away) are preserved albeit
>shifted from their original positions?

``Implementation-defined'' refers to the entire resulting value. An
implementation could document and implement the behavior ``whenever a
signed integral value with a 1 in its sign bit is shifted right, the
resulting value is 42''.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Florian Weimer]

Joe Maun <reply_to@yahoo.com> writes:

> This doesn't matter in this case. The value that the vacated bits take
> is indeed implementation defined, but the sign bit must reliably be
> shifted into the required position, since nothing frees it from the
> requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
> positions".

What abound sign/magnitude representation of signed integers?

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Florian Weimer wrote:
> 
> Joe Maun <reply_to@yahoo.com> writes:
> 
> > This doesn't matter in this case. The value that the vacated bits take
> > is indeed implementation defined, but the sign bit must reliably be
> > shifted into the required position, since nothing frees it from the
> > requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
> > positions".
> 
> What abound sign/magnitude representation of signed integers?

What about them?

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Florian Weimer]

Joe Maun <reply_to@yahoo.com> writes:

>> > This doesn't matter in this case. The value that the vacated bits take
>> > is indeed implementation defined, but the sign bit must reliably be
>> > shifted into the required position, since nothing frees it from the
>> > requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
>> > positions".
>> 
>> What about sign/magnitude representation of signed integers?
>
> What about them?

The sign bit won't be shifted right, so you can't extract it using the
method given above.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Florian Weimer wrote:
> 
> Joe Maun <reply_to@yahoo.com> writes:
> 
> >> > This doesn't matter in this case. The value that the vacated bits take
> >> > is indeed implementation defined, but the sign bit must reliably be
> >> > shifted into the required position, since nothing frees it from the
> >> > requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit
> >> > positions".
> >>
> >> What about sign/magnitude representation of signed integers?
> >
> > What about them?
> 
> The sign bit won't be shifted right, so you can't extract it using the
> method given above.

I fail to see your point. Why wouldn't the sign bit be shifted right in
sign magnitude representation? The quote from the standard above seems
clear - and it applies to a signed magnitude implementation as well.

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Florian Weimer]

Joe Maun <reply_to@yahoo.com> writes:

> I fail to see your point. Why wouldn't the sign bit be shifted right in
> sign magnitude representation? The quote from the standard above seems
> clear - and it applies to a signed magnitude implementation as well.

What about this quote from the standard, then?

| 3.4.1
| [#1] implementation-defined behavior
| unspecified behavior where each implementation documents how
| the choice is made
|
| [#2] EXAMPLE  An example of implementation-defined  behavior
| is  the  propagation  of  the  high-order  bit when a signed
| integer is shifted right.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Florian Weimer wrote:
> 
> Joe Maun <reply_to@yahoo.com> writes:
> 
> > I fail to see your point. Why wouldn't the sign bit be shifted right in
> > sign magnitude representation? The quote from the standard above seems
> > clear - and it applies to a signed magnitude implementation as well.
> 
> What about this quote from the standard, then?
> 
> | 3.4.1
> | [#1] implementation-defined behavior
> | unspecified behavior where each implementation documents how
> | the choice is made
> |
> | [#2] EXAMPLE  An example of implementation-defined  behavior
> | is  the  propagation  of  the  high-order  bit when a signed
> | integer is shifted right.

I'm afraid you missed the point. As has already been pointed out, the
discussion isn't about the new high-order bits that the shift
introduces, which is what the quote above mentions. Everybody agrees
that that's implementation defined. The question is what about the bits
that already exist - are they guaranteed to be reliably shifted right? I
say yes, some say no.

If anything, the quote above strongly hints that the intention of the
standard is as I argue, since it only mentions the propagation of the
_high order bit_ as implementation defined.

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Kaz Kylheku]

In article <3B8B1130.97FFDD66@yahoo.com>, Joe Maun wrote:
>Florian Weimer wrote:
>> 
>> Joe Maun <reply_to@yahoo.com> writes:
>> 
>> > I fail to see your point. Why wouldn't the sign bit be shifted right in
>> > sign magnitude representation? The quote from the standard above seems
>> > clear - and it applies to a signed magnitude implementation as well.
>> 
>> What about this quote from the standard, then?
>> 
>> | 3.4.1
>> | [#1] implementation-defined behavior
>> | unspecified behavior where each implementation documents how
>> | the choice is made
>> |
>> | [#2] EXAMPLE  An example of implementation-defined  behavior
>> | is  the  propagation  of  the  high-order  bit when a signed
>> | integer is shifted right.
>
>I'm afraid you missed the point. As has already been pointed out, the
>discussion isn't about the new high-order bits that the shift
>introduces, which is what the quote above mentions. Everybody agrees
>that that's implementation defined. The question is what about the bits
>that already exist - are they guaranteed to be reliably shifted right? I
>say yes, some say no.

I have a C99 draft copy which says:

``If E1 has a signed type, and a negative value, the resulting value
is implementation-defined.''

What is so hard to understand about this? 

There is absolutely no ambiguity about what it means for a resulting
value to be implementation-defined. This is not some gray area of
the language about which only experts can have doubts.

Implementation-defined could mean that the value 42 is always computed
regardless of the value of the remaining bits, or the shift amount.

If the intent was only to leave the treatment of the sign bit to
the implementors, then the text would say something else entirely,
like perhaps ``If E1 has a signed type and a negative value, it is
implementation-defined whether or not the sign bit is involved in the
shift operation. If it is involved, it's implementation-defined whether
or not it is replaced by a 1 or 0 bit''.

>If anything, the quote above strongly hints that the intention of the
>standard is as I argue, since it only mentions the propagation of the
>_high order bit_ as implementation defined.

Computing the value 42 is a perfect example of such propagation.
The sign bit propagates to bit positions 1, 3 and 4. Its complemented
value propagates to all other bits.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Kaz Kylheku wrote:
> 
> In article <3B8B1130.97FFDD66@yahoo.com>, Joe Maun wrote:
[...]
> >introduces, which is what the quote above mentions. Everybody agrees
> >that that's implementation defined. The question is what about the bits
> >that already exist - are they guaranteed to be reliably shifted right? I
> >say yes, some say no.
> 
> I have a C99 draft copy which says:
> 
> ``If E1 has a signed type, and a negative value, the resulting value
> is implementation-defined.''
> 
> What is so hard to understand about this?
> 
> There is absolutely no ambiguity about what it means for a resulting
> value to be implementation-defined.

Right. However, while the value computed is implementation-defined, the
state of some bits is not necessarily so. Unlike most other operators,
the shift operators are defined both in terms of bits *and* values, two
different concepts.

When a particular aspect of the standard is implementation defined, the
behavior chosen by the implementation has no license to violate a
different aspect of the standard. So while the *whole* value is indeed
implementation defined (there is no such thing as a partial value), I
don't see where it gets the license to violate "The result of E1 >> E2
is E1 right-shifted E2 bit positions", which is not specified in terms
of values but in terms of bits.

So while the value of the expression is explicitly implementation
defined, the state of the bits that existed before the shift are well
defined by the first sentence of that clause, which is _not_
contradicted by the quote "the resulting value is
implementation-defined", since they are two different aspects of the
shift operators.

> This is not some gray area of
> the language about which only experts can have doubts.

Obviously, since I too have doubts. Since you mentioned "experts", it
may be interesting to point out that I changed my position on this after
I was corrected by Lawrence K. when I claimed as you do now. See:

http://groups.google.com/groups?as_umsgid=984786377snz%40genesis.demon.co.uk

For a definitive answer (or more likely endless debate) perhaps this
should be posted to comp.std.c(++).

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Kaz Kylheku]

In article <3B8BD171.32C155D2@yahoo.com>, Joe Maun wrote:
>Kaz Kylheku wrote:
>> 
>> In article <3B8B1130.97FFDD66@yahoo.com>, Joe Maun wrote:
>[...]
>> >introduces, which is what the quote above mentions. Everybody agrees
>> >that that's implementation defined. The question is what about the bits
>> >that already exist - are they guaranteed to be reliably shifted right? I
>> >say yes, some say no.
>> 
>> I have a C99 draft copy which says:
>> 
>> ``If E1 has a signed type, and a negative value, the resulting value
>> is implementation-defined.''
>> 
>> What is so hard to understand about this?
>> 
>> There is absolutely no ambiguity about what it means for a resulting
>> value to be implementation-defined.
>
>Right. However, while the value computed is implementation-defined, the
>state of some bits is not necessarily so.

An implementation-defined result gives the implementor complete freedom
to choose the algorithm by which the result is selected.  It's the same
as unspecified behavior, except for the requirement to document.

If the standard wanted to narrow down the selection, then the wording
would contain the necessary refinements, with references to the behavior
of particular bits.

>Unlike most other operators,
>the shift operators are defined both in terms of bits *and* values, two
>different concepts.

I don't see any reference to bits in the sentence ``If E1 has a signed
type, and a negative value, the resulting value is implementation-defined''.

>When a particular aspect of the standard is implementation defined, the
>behavior chosen by the implementation has no license to violate a
>different aspect of the standard. So while the *whole* value is indeed
>implementation defined (there is no such thing as a partial value), I
>don't see where it gets the license to violate "The result of E1 >> E2
>is E1 right-shifted E2 bit positions", which is not specified in terms
>of values but in terms of bits.

The entire paragraph from C99 says this:

	The result of E1 >> E2 is right shifted E2 bit positions.
	If E1 has an unsigned type, or if E1 has a signed type and
	a nonnegative value, the value of the result is the integral
	part of the quotient of E1 divided by the quantity, 2 raised to
	the power of E2. If E1 has a signed type and a negative value,
	the resulting value is implementation-defined.

So you see, when the result is not implementation-defined, it is actually
defined *arithmetically* as the quotient of an integer division by a power
of two.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Kaz Kylheku wrote:

> The entire paragraph from C99 says this:
> 
>         The result of E1 >> E2 is right shifted E2 bit positions.
>         If E1 has an unsigned type, or if E1 has a signed type and
>         a nonnegative value, the value of the result is the integral
>         part of the quotient of E1 divided by the quantity, 2 raised to
>         the power of E2. If E1 has a signed type and a negative value,
>         the resulting value is implementation-defined.
> 
> So you see, when the result is not implementation-defined, it is actually
> defined *arithmetically* as the quotient of an integer division by a power
> of two.

The *value* is defined arithmetically, while the bit positions are
defined in terms of bit-shifts. Both are properties of the shift
operator. When one is implementation defined, the other may still be
well defined. What do you think the first sentence is there for?

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Kaz Kylheku]

In article <3B8BED46.3DEE945B@yahoo.com>, Joe Maun wrote:
>Kaz Kylheku wrote:
>
>> The entire paragraph from C99 says this:
>> 
>>         The result of E1 >> E2 is right shifted E2 bit positions.
>>         If E1 has an unsigned type, or if E1 has a signed type and
>>         a nonnegative value, the value of the result is the integral
>>         part of the quotient of E1 divided by the quantity, 2 raised to
>>         the power of E2. If E1 has a signed type and a negative value,
>>         the resulting value is implementation-defined.
>> 
>> So you see, when the result is not implementation-defined, it is actually
>> defined *arithmetically* as the quotient of an integer division by a power
>> of two.
>
>The *value* is defined arithmetically, while the bit positions are
>defined in terms of bit-shifts. Both are properties of the shift

Under ones' complement, the bit pattern 1111...111 is non-negative;
it represents the value zero. When this is right shifted by 1, it must
result in the value 0. That value could be represented as 0000...00
or 1111...11.

>operator. When one is implementation defined, the other may still be
>well defined. What do you think the first sentence is there for?

I think it's superflous text that helps to clarify what the operator
is generally for. The subsequent sentences form an exhaustive partition
of all the possibilities: unsigned E1, non-negative signed E1,
and negative signed E1. Each partition of the E1 input is assigned
a behavior. The first two partitions have an arithmetically defined
resulting value. That value is positive, and therefore it has a
corresponding portable binary representation. So, effectively, in these
first two partitions, bit shifting behavior is specified implicitly
as a division by a power of two, without any useful contribution
from the first sentence.  The third partition leads to an
implementation-defined value, which could be anything.

If these sentences did not provide semantics for all the partitions,
then the first sentence would apply to the remaining cases that
are not covered.

So for instance, if nothing were mentioned about the handling of an
unsigned E1, then the interpretation would be that E1 is right shifted
E2 bit positions.

I believe that you have to apply the text which has the most specific
semantics for a given case; it overrides any general text.

The general text is that E1 >> E2 is E1 right shifted by E2 bits.
This is obviously not the case if the sign bit does not shift
along with the others.  If the value of the sign bit does shift along
with the others, then the only question that remains is what 
replaces its value: is a 1 shifted in or a 0? Under two's complement,
these two possibilities are called arithmetic and logical shift.  If the
only question were what value is shifted in, then the standard could
easily have specific text to that effect.  As it stands, the general
text is at odds with the specific text for negative E1. The specific
text dominates.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Kaz Kylheku]

In article <3B8BED46.3DEE945B@yahoo.com>, Joe Maun wrote:
>Kaz Kylheku wrote:
>
>> The entire paragraph from C99 says this:
>> 
>>         The result of E1 >> E2 is right shifted E2 bit positions.
>>         If E1 has an unsigned type, or if E1 has a signed type and
>>         a nonnegative value, the value of the result is the integral
>>         part of the quotient of E1 divided by the quantity, 2 raised to
>>         the power of E2. If E1 has a signed type and a negative value,
>>         the resulting value is implementation-defined.
>> 
>> So you see, when the result is not implementation-defined, it is actually
>> defined *arithmetically* as the quotient of an integer division by a power
>> of two.
>
>The *value* is defined arithmetically, while the bit positions are
>defined in terms of bit-shifts. Both are properties of the shift

Under ones' complement, the bit pattern 1111...111 is non-negative;
it represents the value zero. When this is right shifted by 1, it must
result in the value 0. That value could be represented as 0000...00
or 1111...11.

What about the sign-magnitude zero, 1000...000? When that is shifted
right, you can get 1000..000 or 0000..000. Is that a bit shift?

>operator. When one is implementation defined, the other may still be
>well defined. What do you think the first sentence is there for?

I think it's superflous text that helps to clarify what the operator
is generally for. The subsequent sentences form an exhaustive partition
of all the possibilities: unsigned E1, non-negative signed E1,
and negative signed E1. Each partition of the E1 input is assigned
a behavior. The first two partitions have an arithmetically defined
resulting value. That value is positive, and therefore it has a
corresponding portable binary representation. So, effectively, in these
first two partitions, bit shifting behavior is specified implicitly
as a division by a power of two, except in cases like the alternate zeros
in ones' complement and sign-magnitude.  The third partition leads to
an implementation-defined value, which could be anything.

If these sentences did not provide semantics for all the partitions,
then the first sentence would apply to the remaining cases that
are not covered.

So for instance, if nothing were mentioned about the handling of an
unsigned E1, then the interpretation would be that E1 is right shifted
E2 bit positions.

I believe that you have to apply the text which has the most specific
semantics for a given case; it overrides any general text.

The general text is that E1 >> E2 is E1 right shifted by E2 bits.
This is obviously not the case if the sign bit does not shift
along with the others.  If the value of the sign bit does shift along
with the others, then the only question that remains is what 
replaces its value: is a 1 shifted in or a 0? Under two's complement,
these two possibilities are called arithmetic and logical shift.  If the
only question were what value is shifted in, then the standard could
easily have specific text to that effect.  As it stands, the general
text is at odds with the specific text for negative E1. The specific
text dominates.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Joe Maun]

Kaz Kylheku wrote:
> 
> In article <3B8BED46.3DEE945B@yahoo.com>, Joe Maun wrote:
> >Kaz Kylheku wrote:
> >
> >> The entire paragraph from C99 says this:
> >>
> >>         The result of E1 >> E2 is right shifted E2 bit positions.
> >>         If E1 has an unsigned type, or if E1 has a signed type and
> >>         a nonnegative value, the value of the result is the integral
> >>         part of the quotient of E1 divided by the quantity, 2 raised to
> >>         the power of E2. If E1 has a signed type and a negative value,
> >>         the resulting value is implementation-defined.
> >>
> >> So you see, when the result is not implementation-defined, it is actually
> >> defined *arithmetically* as the quotient of an integer division by a power
> >> of two.
> >
> >The *value* is defined arithmetically, while the bit positions are
> >defined in terms of bit-shifts. Both are properties of the shift
> 
> Under ones' complement, the bit pattern 1111...111 is non-negative;

Wrong. If it's not a trap representation it's *negative* zero (ISO/IEC
9899:1999 - 6.2.6.2[2]).

> it represents the value zero. When this is right shifted by 1, it must
> result in the value 0.

Since it is a negative value, the resulting value is
implementation-defined. The resulting bits must have the form ?111...11.

> That value could be represented as 0000...00
> or 1111...11.
> 
> What about the sign-magnitude zero, 1000...000?

That too is negative zero, so the above applies.

> When that is shifted
> right, you can get 1000..000 or 0000..000. Is that a bit shift?

You get ?100...00.

> easily have specific text to that effect.  As it stands, the general
> text is at odds with the specific text for negative E1. The specific
> text dominates.

Is it really at odds with the specific text? Or can both be satisfied? I
think both can be satisfied for reasons I have already mentioned. You
think they are meant to be at odds. I don't think I have anything to add
to this, so I probably won't, unless you come up with something really
convincing.

-- 
Joe Maun
Montreal, QC
Canada

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Florian Weimer]

Joe Maun <reply_to@yahoo.com> writes:

>> Under ones' complement, the bit pattern 1111...111 is non-negative;
>
> Wrong. If it's not a trap representation it's *negative* zero (ISO/IEC
> 9899:1999 - 6.2.6.2[2]).
>
>> it represents the value zero. When this is right shifted by 1, it must
>> result in the value 0.
>
> Since it is a negative value, the resulting value is
> implementation-defined. The resulting bits must have the form ?111...11.

How do you derive that from the standard?  From the phrase 'The result
of E1 >> E2 is E1 right-shifted E2 bit positions.'?  What happens when
we write down the bits starting with the least significant bit?

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Larry Kilgallen]

In article <87d75fhaod.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> Joe Maun <reply_to@yahoo.com> writes:
> 
>>> Under ones' complement, the bit pattern 1111...111 is non-negative;
>>
>> Wrong. If it's not a trap representation it's *negative* zero (ISO/IEC
>> 9899:1999 - 6.2.6.2[2]).
>>
>>> it represents the value zero. When this is right shifted by 1, it must
>>> result in the value 0.
>>
>> Since it is a negative value, the resulting value is
>> implementation-defined. The resulting bits must have the form ?111...11.
> 
> How do you derive that from the standard?  From the phrase 'The result
> of E1 >> E2 is E1 right-shifted E2 bit positions.'?  What happens when
> we write down the bits starting with the least significant bit?

That might depend on whether your "start" of writing is on
the left (European style) or the right (Arabic style) :-)

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Florian Weimer]

Joe Maun <reply_to@yahoo.com> writes:

> The *value* is defined arithmetically, while the bit positions are
> defined in terms of bit-shifts.

But where?  I haven't seen any definition of the term 'bit-shift'.  It
seems that you consider the introductory explanation of the relevant
parapgraph a definition, but most people do not seem to agree.

Sometimes I wish there was another version of the C standard which
contained the strictly normative parts. ;-)

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[B.Gaffney]

Joe Maun <reply_to@yahoo.com> wrote in message news:<3B8BED46.3DEE945B@yahoo.com>...
> Kaz Kylheku wrote:
> 
> > The entire paragraph from C99 says this:
> > 
> >         The result of E1 >> E2 is right shifted E2 bit positions.
> >         If E1 has an unsigned type, or if E1 has a signed type and
> >         a nonnegative value, the value of the result is the integral
> >         part of the quotient of E1 divided by the quantity, 2 raised to
> >         the power of E2. If E1 has a signed type and a negative value,
> >         the resulting value is implementation-defined.
> > 
> > So you see, when the result is not implementation-defined, it is actually
> > defined *arithmetically* as the quotient of an integer division by a power
> > of two.
> 
> The *value* is defined arithmetically, while the bit positions are
> defined in terms of bit-shifts. Both are properties of the shift
> operator. When one is implementation defined, the other may still be
> well defined. What do you think the first sentence is there for?

But on a sign-magnitude machine it may make sense to exclude the sign
bit from this shift.  Is there anything in the standard which
specifies the bit layout or what a "right shift" is?  Does it specify
that it must include the sign bit?

From a practical perspective, if a compiler were implemented on such a
machine, it could take advantage of this "implementation-defined"
permission to allow it to optimize A/2 as A>>1 (i.e. if A = 42, A/2 =
A>>1 = 21 and if B = -42, B/2 = B>>1 = -21), which it couldn't do for
a signed type otherwise (assuming a 16-bit sign-magnitude type, B>>1 =
32747 <> B/2).

There are two "expectation" people have of a right shift (whatever the
standard actually says):  it is equivalent to a division by a power of
two and the sign bit is shifted.  On a sign-magnitude machine one of
the two will always fail, and some code with it.  It's up the the
implementation which way is 'best'.  (Good reason to stick with 2's
complement.)

BTW, what if a machine were implemented with the LSB on the left and
the MSB on the right?  Would A>>1 actually require a _left_ shift (per
the A/2 requirement above)?

          --Brian

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Darren New]

> BTW, what if a machine were implemented with the LSB on the left and
> the MSB on the right?  Would A>>1 actually require a _left_ shift (per
> the A/2 requirement above)?

Err, "left" and "right" don't make any sense when talking about machine
implementations. There's no reason to assume that different bits of the
same byte are in the same bank of memory chips, let alone where they are
on the die. :-)

Arabic numbers are written LSB on the right (which is the *first*
position in Arabic). This actually makes a lot more sense than having
the MSB come first.

Followups to comp.lang.c where they belong, thanks. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[David Starner]

On Wed, 22 Aug 2001 20:34:27 GMT, Kaz Kylheku <kaz@ashi.footprints.net> wrote:
> So we could say a number of things besides ``sox is written in the
> wrong programming language''.

Go ahead, blame the programmer. But don't forget that this is a real
program, in real use. The real world is not going to give you nice
friendly programs. Several months ago, Linux Weekly News pointed out
a email to linux-kernel showing stupid bugs in the Linux kernel; stuff 
like a = b++ + b++, and other undefined stuff. But, still, if that
blows up in the programmer's face, it's his fault, isn't it.
 
> If this function is submitted for critique to comp.lang.c, the errors
> in it will be shaken out in an instant, and a maximally portable version
> will soon appear that will work on C implementations with unusual sizes
> of integral types, CHAR_BIT other than 8, and sign-magnitude or ones'
> complement representations for negative numbers. Try it!

Cool. Should I upload the entire Linux kernel in one post, or should I
break it into two or three?

Yeah, a group of experts can pound a short piece of code into near
perfection in a short period of time, irrespective of language. The
question is how can Joe Random programmer turn out the largest amount
of code in the shortest time with the fewest bugs?

> If I ported the essence of the algorithm to Common Lisp (for instance),
> then it will just work. 

With the restriction of being able to output the music to speakers
in real-time on a 486 or Pentium?

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Kaz Kylheku]

In article <9m1skf$8q81@news.cis.okstate.edu>, David Starner wrote:
>On Wed, 22 Aug 2001 20:34:27 GMT, Kaz Kylheku <kaz@ashi.footprints.net> wrote:
>> So we could say a number of things besides ``sox is written in the
>> wrong programming language''.
>
>Go ahead, blame the programmer. But don't forget that this is a real
>program, in real use.

I know what sox is, I use it.

The Ada and Lisp communities haven't decided to develop a replacement
for sox so far, so I'll just have to use the crummy C program for now
with its broken a-law conversion and all.

Where the culture is at now is that a large chunk of the useful programs
that others seem to be willing to share with me are written in C (or
some platform-specific dialects of it).

>> If I ported the essence of the algorithm to Common Lisp (for instance),
>> then it will just work. 
>
>With the restriction of being able to output the music to speakers
>in real-time on a 486 or Pentium?

There are Lisp compilers that produce machine code (e.g. CMUCL
http:/www.cons.org/cmucl). Performance-critical sections of code can be
tuned with various declarations to help speed things up.

It's hard to make concrete performance statements about abstract
languages!

If you make your selection of hardware slow and outdated enough, I
will eventually have to use assembly language to meet the performance
requirement, and at some point, I won't be able to meet it at all.

If the only way to meet a performance requirement is to use a stone age
programming language, or even assembly language, then by all means use it.

That doesn't justify the use of these languages for every single
programming task, or in fact for any part of a program except a few
performance hotspots.

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Jean-Pierre Rosen]

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


"Kaz Kylheku" <kaz@ashi.footprints.net> a �crit dans le message news: nHUg7.93012$B37.2083519@news1.rdc1.bc.home.com...
> So we could say a number of things besides ``sox is written in the
> wrong programming language''.
> [...]
>
> Would you hire the programmer who wrote this function, to work with you
> on a project in *any* programming language?
>
Yes, programmers make errors.

Two quotes that I love to bring together:
From one of the first books about C by K&R:
"C was designed on the assumption that the programmer is someone sensible who knows what he's doing"

From the introduction of the Ada Reference Manual:
"Ada was designed with the concern of programming as a human activity"

The fact that these starting hypothesis lead to two completely different philosophies of languages is left as a subject for
meditation...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Richard Bos]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote:

> From one of the first books about C by K&R:
> "C was designed on the assumption that the programmer is someone sensible who knows what he's doing"
> 
> From the introduction of the Ada Reference Manual:
> "Ada was designed with the concern of programming as a human activity"
> 
> The fact that these starting hypothesis lead to two completely different philosophies
> of languages is left as a subject for meditation...

<troll level="quite high>

The conclusion is obvious. C was designed for professionals; Ada for
amateurs.

</troll>

<nasty g>

Richard

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[James Rogers]

Richard Bos wrote:
> 
> "Jean-Pierre Rosen" <rosen@adalog.fr> wrote:
> 
> > From one of the first books about C by K&R:
> > "C was designed on the assumption that the programmer is someone sensible who knows what he's doing"
> >
> > From the introduction of the Ada Reference Manual:
> > "Ada was designed with the concern of programming as a human activity"
> >
> > The fact that these starting hypothesis lead to two completely different philosophies
> > of languages is left as a subject for meditation...
> 
> <troll level="quite high>
> 
> The conclusion is obvious. C was designed for professionals; Ada for
> amateurs.
> 
> </troll>

<troll level="current amplitude">

No, C was designed by naive optomists. Ada was designed by realists.

</troll>

Jim Rogers
Colorado Springs, Colorado USA

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Marin David Condic]

Optimists are forever being disappointed. Pessimists are occasionally
pleasantly surprised.

I think the invention of C was a direct attempt to violate Murphy's Law. To
paraphrase Homer Simpson: "In the Ada community, we obey Murphy's Law!" :-)

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/


"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3B84F0DA.BE8B4D61@worldnet.att.net...
>
> <troll level="current amplitude">
>
> No, C was designed by naive optomists. Ada was designed by realists.
>
> </troll>

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Samuel T. Harris]

Richard Bos wrote:
> 
> "Jean-Pierre Rosen" <rosen@adalog.fr> wrote:
> 
> > From one of the first books about C by K&R:
> > "C was designed on the assumption that the programmer is someone sensible who knows what he's doing"
> >
> > From the introduction of the Ada Reference Manual:
> > "Ada was designed with the concern of programming as a human activity"
> >
> > The fact that these starting hypothesis lead to two completely different philosophies
> > of languages is left as a subject for meditation...
> 
> <troll level="quite high>
> 
> The conclusion is obvious. C was designed for professionals; Ada for
> amateurs.
> 
> </troll>
> 
> <nasty g>
> 
> Richard

Of course, _any_ professional engaged in a code base which
severly exceeds his span of attention and control can only be
expected to behave as well as an amateur.

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

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Ted Dennison]

In article <3b84cf73.1201990748@news.worldonline.nl>, Richard Bos says...
>
>> The fact that these starting hypothesis lead to two completely different 
>> philosophies of languages is left as a subject for meditation...
>The conclusion is obvious. C was designed for professionals; Ada for
>amateurs.

There are two problems with that statement:

1) The only differece between "professionals" and "ameteurs" in our industry is
that one of them is paid.

2) A little digging into the history of both languages will actually show you
that more or less the exact *opposite* of what you said was true. 

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

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Richard Bos]

Ted Dennison<dennison@telepath.com> wrote:

> In article <3b84cf73.1201990748@news.worldonline.nl>, Richard Bos says...
>
> >The conclusion is obvious. C was designed for professionals; Ada for
> >amateurs.
> 
> There are two problems with that statement:
> 
> 1) The only differece between "professionals" and "ameteurs" in our industry is
> that one of them is paid.
> 
> 2) A little digging into the history of both languages will actually show you
> that more or less the exact *opposite* of what you said was true. 

Good Cthulhu. The number of imbecilic Merkins who take irony seriously,
_even_ when marked as such, is truly stunning. I'm appalled.

Richard

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[David Starner]

On Thu, 23 Aug 2001 09:42:58 GMT, Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
><troll level="quite high>
> 
> The conclusion is obvious. C was designed for professionals; Ada for
> amateurs.
> 
></troll>

In which case, it has been satisfactorily proved that the Sox 
programmers are amateurs and should have been using Ada. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[CBFalconer]

David Starner wrote:
> 
> On Thu, 23 Aug 2001 09:42:58 GMT, Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
> ><troll level="quite high>
> >
> > The conclusion is obvious. C was designed for professionals;
> > Ada for amateurs.
> >
> ></troll>
> 
> In which case, it has been satisfactorily proved that the Sox
> programmers are amateurs and should have been using Ada.

Just because the Red Sox are 5 games behind the Yankees?

-- 
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: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Richard Riehle]

Richard Bos wrote:

> The conclusion is obvious. C was designed for professionals; Ada for
> amateurs.

I am no fan of the C family of languages.  However,  neither C or C++ are
inherently evil.   It is simply that they are more fraught with peril than
Ada or Modula-X.  Dr. Stroustrup did a brilliant job of making C a better,
safer language.    The inherent peril of C could not be totally eradicated
in the C++ model.   Subsequent efforts to improve C++ are commendable
and progress is evident.  Still, the underlying peril persists.    Mr. Gosling
and his colleagues made some good progress in eliminating some of the
perils of C and C++ with their design of Java.   Still, many of those
underlying perils persist.

The fact is that, even with the impressive progress that has been made in
the improvement of the C family of languages, they still do not measure
up to the inherent safety one finds in Ada.   It is very difficult to take a
language where the default is unsafe and promote it to one that is more
safe.   In Ada, the default is "safe" and that is what makes it appropriate
for software targeted to applications where lives are at stake.   I find
it odd that this is so difficult to understand.   Perhaps those in the community
that favors the C family of languages simply don't know Ada well enough
to comprehend the difference.   Perhaps they simply have other motives.

Whatever the case, no one is going to be persuaded by arguments presented
in this forum.   C++ will continue to be used successfully for a variety of
software applications, as will Ada.  Those of of us who prefer Ada will
still prefer it.  Those who prefer C++ will still choose it over Ada.  Those
who wish to rush off to the latest fad will choose Ruby, Erlang, C#, Java,
or whatever they, as early adopters, find interesting.

In my mind, choosing the right tool for the right job is important.   For anything
safety-related, Ada is still the right choice.   For anything else, I have no
serious objection to using C++.  It is a pretty well-designed attempt at
overcoming the perils of C.    Meanwhile,  there is someone, in some lab
somewhere inventing the safety-critical successor to Eiffel that will take
the industry by storm and make everything we currently favor obsolete.

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

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[Dan Cross]

In article <3B855750.466C59CF@yahoo.com>,
CBFalconer  <cbfalconer@worldnet.att.net> wrote:
>> In which case, it has been satisfactorily proved that the Sox
>> programmers are amateurs and should have been using Ada.
>
>Just because the Red Sox are 5 games behind the Yankees?

Well, honestly, whaddya expect?  Of course they're behind the Yankees;
they're an inferior team.

	- Dan C.

(I guess I should note that I live a block away from the #4 train that
stops at Yankee Stadium in the Bronx; maybe I'm slightly biased.)

Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...)

[CBFalconer]

Dan Cross wrote:
> 
> In article <3B855750.466C59CF@yahoo.com>,
> CBFalconer  <cbfalconer@worldnet.att.net> wrote:
> >> In which case, it has been satisfactorily proved that the Sox
> >> programmers are amateurs and should have been using Ada.
> >
> >Just because the Red Sox are 5 games behind the Yankees?
> 
> Well, honestly, whaddya expect?  Of course they're behind the Yankees;
> they're an inferior team.
> 
>         - Dan C.
> 
> (I guess I should note that I live a block away from the #4 train that
> stops at Yankee Stadium in the Bronx; maybe I'm slightly biased.)

You are a braver man than I am.

-- 
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 to make Ada a dominant language

[Gary Lisyansky]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0107292308.d1192fc@posting.google.com...
> 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.

Ada is known to favour code reader over the code writer, while Python tends
to be a typical "write only" language.

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

This makes whitespace the part of the language syntax. In practice, it's not
convenient, and adds *extremely nasty* tab/space problems. In common, it's a
bug generator.

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

"Physical" line is not an element of Ada syntax. Writing statements in one
line or several lines is purely the question of style which allows for more
flexibility and readability. Changing this doesn't make any sense. In fact,
suggestions 1 and 2 are in contradiction to the very idea of a free- form
language.

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

Exactly the same amount of typing. Only the reverse order of words that
seems to be less readable.

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

No. Ones who like Python will continue to use Python.

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

Clearly the first one ("old syntax"), because it puts user- readable
variable name first, and doesn't force the user to locate this name
somewhere between the [probably qualified] type name and the initialiser.

Gary

Re: How to make Ada a dominant language

[Gerhard Häring]

Gary Lisyansky wrote:

> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0107292308.d1192fc@posting.google.com...
> 
>>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.

>>
> 
> Ada is known to favour code reader over the code writer, while Python tends
> to be a typical "write only" language.


Python does it both. The code is easy to read and easy to write. And it 
is good for quick scripting tasks, too.


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


I don't see how changing the syntax can make a language more popular. If 
you want to lure more people into Ada, you'd have to change the syntax 
to something C-like (yuck!).


> This makes whitespace the part of the language syntax. In practice, it's not
> convenient, and adds *extremely nasty* tab/space problems. In common, it's a
> bug generator.


In many people's experience, it _is_ convenient. My policy is that tabs 
are evil and should never be used except where they absolutely cannot be 
avoided (Makefiles). The unusual fact that whitespace has meaning is 
only annoying beginning Python programmers who use shitty editors.


-- Gerhard

Re: How to make Ada a dominant language

[Gary Lisyansky]

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


"Gerhard H�ring" <gerhard.nospam@bigfoot.de> wrote in message
news:3B654276.4040707@bigfoot.de...
>
> Python does it both. The code is easy to read and easy to write. And it
> is good for quick scripting tasks, too.

The core of the answer is "for quick scripting tasks". One can write a well-
readable code in Python, but most code is not of this quality, especially
because of absence of parameter type information.
>
>
> >>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.
>
>
> I don't see how changing the syntax can make a language more popular. If
> you want to lure more people into Ada, you'd have to change the syntax
> to something C-like (yuck!).

Agreed partially. Delphi and VB both have Algol- style syntax, and they are
popular. In fact, they are much more popular than C++ Builder that follows
BCPL syntax convention.
>
>
> > This makes whitespace the part of the language syntax. In practice, it's
not
> > convenient, and adds *extremely nasty* tab/space problems. In common,
it's a
> > bug generator.
>
>
> In many people's experience, it _is_ convenient. My policy is that tabs
> are evil and should never be used except where they absolutely cannot be
> avoided (Makefiles). The unusual fact that whitespace has meaning is
> only annoying beginning Python programmers who use shitty editors.

Given the source file is a text file, it must be quite easily readable and
editable in a conventional ASCII text editor. Any "non- shitty" editor is
not a part of language definition. A more serious (far more) thing is that
absence of end statement makes it very easy to introduce a very bad kind of
bugs (unintended inclusion or exclusion of a statement) that are so
characteristic for C++ and Java programs and are often difficult to track.
In common, it's a convenience at a price of reliability. Even though in Java
or C++ it's allowed not to use {} if a statement like if() or for() contains
only one executable statement, it's frequently considered a bad practice.
IMHO, it's not an co-incidence that we don't know too many practically used
non- free- form languages.
>
>
> -- Gerhard
>

Gary

Re: How to make Ada a dominant language

[Russ Paielli]

Gary Lisyansky wrote:
> 
> "Gerhard H�ring" <gerhard.nospam@bigfoot.de> wrote in message
> news:3B654276.4040707@bigfoot.de...
> >
> > Python does it both. The code is easy to read and easy to write. And it
> > is good for quick scripting tasks, too.
> 
> The core of the answer is "for quick scripting tasks". One can write a well-
> readable code in Python, but most code is not of this quality, especially
> because of absence of parameter type information.

Of course Python is intended for a different type of application than
Ada is intended for. I am not proposing for a second that Ada become
Python. I am simply proposing that Ada borrow some of Python's elegant
syntax. The underlying fundamentals of Ada would not be changed one
iota.

Russ

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

Russ Paielli wrote:
> Gary Lisyansky wrote:
> > "Gerhard H�ring" <gerhard.nospam@bigfoot.de> wrote in message
> > news:3B654276.4040707@bigfoot.de...
> > >
> > > Python does it both. The code is easy to read and easy to write. And it
> > > is good for quick scripting tasks, too.
> >
> > The core of the answer is "for quick scripting tasks". One can write a well-
> > readable code in Python, but most code is not of this quality, especially
> > because of absence of parameter type information.
> 
> Of course Python is intended for a different type of application than
> Ada is intended for. I am not proposing for a second that Ada become
> Python. I am simply proposing that Ada borrow some of Python's elegant
> syntax.

Some of us don't find Python to be "elegant".

> The underlying fundamentals of Ada would not be changed one
> iota.
> 
> Russ

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

Re: How to make Ada a dominant language

[Preben Randhol]

In article <3B654276.4040707@bigfoot.de>, Gerhard H�ring wrote:
> Gary Lisyansky wrote:
> 
>> This makes whitespace the part of the language syntax. In practice, it's not
>> convenient, and adds *extremely nasty* tab/space problems. In common, it's a
>> bug generator.

Yes.
 
> In many people's experience, it _is_ convenient. My policy is that tabs 

Like it is in FORTRAN 77? No, it is not convenient only annoying and a
bug trap. Please explain why it is convenient.


-- 
�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 <3B654276.4040707@bigfoot.de>, Gerhard H�ring wrote:
> > Gary Lisyansky wrote:
> >
> >> This makes whitespace the part of the language syntax. In practice, it's not
> >> convenient, and adds *extremely nasty* tab/space problems. In common, it's a
> >> bug generator.
> 
> Yes.
> 
> > In many people's experience, it _is_ convenient. My policy is that tabs
> 
> Like it is in FORTRAN 77? No, it is not convenient only annoying and a
> bug trap. Please explain why it is convenient.

It is more than "convenient." It FORCES the programmer to use proper
indentation structure, and it assures the reader that the indentation
structure is indeed consistent with the logical structure. It is
completely in the Ada spirit of encouraging good structure and form. It
will ELIMINATE an entire class of bugs.

Russ

Re: How to make Ada a dominant language

[Darren New]

> > Like it is in FORTRAN 77? No, it is not convenient only annoying and a
> > bug trap. Please explain why it is convenient.
> 
> It is more than "convenient." It FORCES the programmer to use proper
> indentation structure, and it assures the reader that the indentation
> structure is indeed consistent with the logical structure. It is
> completely in the Ada spirit of encouraging good structure and form. It
> will ELIMINATE an entire class of bugs.

This regularly comes up in the python newsgroup, where studies showing
the effectiveness of indentation-oriented blocks reduces bugs. Not that
I'm recommending it for Ada, mind. But there have been actual
experiments done showing it works. 

-- 
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 to make Ada a dominant language

[Preben Randhol]

In article <3B65810F.BEF41F2@san.rr.com>, Darren New wrote:
> 
> This regularly comes up in the python newsgroup, where studies showing
> the effectiveness of indentation-oriented blocks reduces bugs. Not that
> I'm recommending it for Ada, mind. But there have been actual
> experiments done showing it works. 

So if you code in Ada and use propper identation (as I expect most do)
you should reduce bugs. :-)

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 <3B65810F.BEF41F2@san.rr.com>, Darren New wrote:
> >
> > This regularly comes up in the python newsgroup, where studies showing
> > the effectiveness of indentation-oriented blocks reduces bugs. Not that
> > I'm recommending it for Ada, mind. But there have been actual
> > experiments done showing it works.
> 
> So if you code in Ada and use propper identation (as I expect most do)
> you should reduce bugs. :-)

That's like saying, "If you code in C++, check all array bounds yourself
(as I expect most do) and you should reduce bugs."

Russ

Re: How to make Ada a dominant language

[Gerhard Häring]

Russ Paielli wrote:

> Preben Randhol wrote:
> 
>>In article <3B65810F.BEF41F2@san.rr.com>, Darren New wrote:
>>
>>>This regularly comes up in the python newsgroup, where studies showing
>>>the effectiveness of indentation-oriented blocks reduces bugs. Not that
>>>I'm recommending it for Ada, mind. But there have been actual
>>>experiments done showing it works.
>>>
>>So if you code in Ada and use propper identation (as I expect most do)
>>you should reduce bugs. :-)
>>
> 
> That's like saying, "If you code in C++, check all array bounds yourself
> (as I expect most do) and you should reduce bugs."

Russ, why do you make a Holy War (tm) for syntax? I don't think this 
helps support your arguments.

-- Gerhard

Re: How to make Ada a dominant language

[Larry Kilgallen]

In article <3B658ABC.BFF1B050@sneakemail.com>, Russ Paielli <18k11tm001@sneakemail.com> writes:
> Preben Randhol wrote:
>> 
>> In article <3B65810F.BEF41F2@san.rr.com>, Darren New wrote:
>> >
>> > This regularly comes up in the python newsgroup, where studies showing
>> > the effectiveness of indentation-oriented blocks reduces bugs. Not that
>> > I'm recommending it for Ada, mind. But there have been actual
>> > experiments done showing it works.
>> 
>> So if you code in Ada and use propper identation (as I expect most do)
>> you should reduce bugs. :-)
> 
> That's like saying, "If you code in C++, check all array bounds yourself
> (as I expect most do) and you should reduce bugs."

And the difference is I can write a program to correct indentation.
But I will not, because others have already done it.

Re: How to make Ada a dominant language

[Darren New]

> And the difference is I can write a program to correct indentation.
> But I will not, because others have already done it.

Do you run that program on every source file before you look at it?
That's what you need to do in many languages, or you'll be misled by the
incorrect indentation.

The alternative is to use an IDE that does that for you, or presents it
with correct indentation regardless. Ada's "end-with-a-label" probably
helps a lot too.

It would be interesting to see a study of reduction in errors based on
indentation-based-blocks vs syntax-colored editors. I suspect the
former's effect is much like the latter's.

-- 
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 to make Ada a dominant language

[Florian Weimer]

Darren New <dnew@san.rr.com> writes:

>> And the difference is I can write a program to correct indentation.
>> But I will not, because others have already done it.
> 
> Do you run that program on every source file before you look at it?

I do (actually, it's part of the IDE in my environment), otherwise the
Ada compiler would choke on it.  Of course, this mode of GNAT is not
conforming to the Ada standard ;-), but I find it very, very helpful,
togehter with the other restrictions imposed by the GNAT style checks.

Re: How to make Ada a dominant language

[Lutz Donnerhacke]

* Darren New wrote:
>> And the difference is I can write a program to correct indentation.
>> But I will not, because others have already done it.
>
>Do you run that program on every source file before you look at it?
>That's what you need to do in many languages, or you'll be misled by the
>incorrect indentation.

My editor does it for me. (adamode from ada.sl, which also shows the
limitations of S-Lang)

Re: How to make Ada a dominant language

[Florian Weimer]

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

>> So if you code in Ada and use propper identation (as I expect most do)
>> you should reduce bugs. :-)
> 
> That's like saying, "If you code in C++, check all array bounds yourself
> (as I expect most do) and you should reduce bugs."

No, it's not, because there are tools which statically check for
correct indentation of Ada code.  (There are no such tools for Python
because Python source code lacks the required redundancy for such
checks.)

Re: How to make Ada a dominant language

[Philip Anderson]

Preben Randhol wrote:
> 
> So if you code in Ada and use propper identation (as I expect most do)
> you should reduce bugs. :-)

It is certainly good practice; I would expect any coding standard to
include rules/guidelines for indentation, ideally with automatic
formatting by the development (Rational Apex is hopeless however).

But I would not expect this to be in the language definition; for one
thing, the appropriate size of indentation must depend upon the width of
display or printout.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: How to make Ada a dominant language

[Florian Weimer]

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

>> Like it is in FORTRAN 77? No, it is not convenient only annoying and a
>> bug trap. Please explain why it is convenient.
> 
> It is more than "convenient." It FORCES the programmer to use proper
> indentation structure, and it assures the reader that the indentation
> structure is indeed consistent with the logical structure. It is
> completely in the Ada spirit of encouraging good structure and form. It
> will ELIMINATE an entire class of bugs.

That's why at least one Ada compiler optionally checks indentation and
refuses to compile code with confusing and inconsistent indentation.

Re: How to make Ada a dominant language

[Darren New]

> That's why at least one Ada compiler optionally checks indentation and
> refuses to compile code with confusing and inconsistent indentation.

So how does it deal with the tab/space problem? Why's that a problem for
Python and not for the Ada indentation-checking tools?

-- 
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 to make Ada a dominant language

[Florian Weimer]

Darren New <dnew@san.rr.com> writes:

> > That's why at least one Ada compiler optionally checks indentation and
> > refuses to compile code with confusing and inconsistent indentation.
> 
> So how does it deal with the tab/space problem? Why's that a problem for
> Python and not for the Ada indentation-checking tools?

Tab characters are not valid source code characters if this compiler
option is activated.

Re: How to make Ada a dominant language

[Darren New]

> > So how does it deal with the tab/space problem? Why's that a problem for
> > Python and not for the Ada indentation-checking tools?
 
> Tab characters are not valid source code characters if this compiler
> option is activated.

FWIW, Python's approach is to forbid mixing of tabs and spaces in the
same indent block. I.e., you can use some number of tabs per indent, or
some number of spaces per indent, but not both. ITabs vs spaces is
actually a pretty rare complaint, judging from the python newsgroup.

-- 
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 to make Ada a dominant language

[Preben Randhol]

On Tue, 31 Jul 2001 16:53:43 GMT, Darren New wrote:
> FWIW, Python's approach is to forbid mixing of tabs and spaces in the
> same indent block. I.e., you can use some number of tabs per indent, or
> some number of spaces per indent, but not both. ITabs vs spaces is
> actually a pretty rare complaint, judging from the python newsgroup.

Sounds like a recipe for a big mess if the source code is edited by
several individuals with different editors. Say one use emacs and
another vim. The first uses tabs and the latter have turned on the
option to turn tabs into spaces for instance...

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

[Darren New]

> Sounds like a recipe for a big mess if the source code is edited by
> several individuals with different editors. Say one use emacs and
> another vim. The first uses tabs and the latter have turned on the
> option to turn tabs into spaces for instance...

The same would be true of the Ada command switch, yes? "Doctor, doctor,
it hurts when I do this!"

Anyway, this *is* caught at compile time in Python, so it's probably not
that big a deal.

-- 
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 to make Ada a dominant language

[Florian Weimer]

Darren New <dnew@san.rr.com> writes:

> > Sounds like a recipe for a big mess if the source code is edited by
> > several individuals with different editors. Say one use emacs and
> > another vim. The first uses tabs and the latter have turned on the
> > option to turn tabs into spaces for instance...
> 
> The same would be true of the Ada command switch, 

It's a GNAT switch, and strictly speaking, GNAT is not conforming to
the Ada standard when it is activated.

> yes? "Doctor, doctor, it hurts when I do this!"

If you use CVS, you have to enforce a common policy regarding tabs
anyway, to keep the diffs clean.

Re: How to make Ada a dominant language

[David Bolen]

Darren New <dnew@san.rr.com> writes:

> > > So how does it deal with the tab/space problem? Why's that a problem for
> > > Python and not for the Ada indentation-checking tools?
>  
> > Tab characters are not valid source code characters if this compiler
> > option is activated.
> 
> FWIW, Python's approach is to forbid mixing of tabs and spaces in the
> same indent block. I.e., you can use some number of tabs per indent, or
> some number of spaces per indent, but not both. ITabs vs spaces is
> actually a pretty rare complaint, judging from the python newsgroup.

Actually, that's not technically Python's approach.  The compiler in
Python has well-defined rules for handling tabs and spaces.  The
parser treats a tab as aligning with the next multiple-of-8 boundary.

The problems tend to arise when people reprogram their editors to use
some non-parser-compliant spread for tab characters, then let the
literal tabs get inserted into the source, and then intermix tabs and
spaces.  The non-standard interval itself is fine if you stick with
tabs (since beyond the parser Python only cares that indentation is
consistent, not how much it is), but the mixture ends up with the
editor showing block structure that doesn't match how the parser will
see it.

In the end, the general concensus is to just stick with spaces (the
major Python editing environments handle this for you transparently).

Given that code written in other languages almost always tends to be
block oriented and formatted, even when the language itself doesn't
care about the block structure, it's really just formalizing something
that well written code exhibits anyway, and reduces the variations on
a theme that you can see in other language code.  By and large, it's
really a non-issue, albeit one that can cause vociferous arguments,
particularly among those just starting to look at Python.

But I would think there's plenty of better points of comparisons with
Python than indentation - and no, I don't personally think Ada would
be better off adopting a whole bunch of Pythonisms.  Both languages
are useful, and to be honest, could probably be quite synergistic in
many applications.  It's already quite common to have a mixture of
Python and C/C++ in applications, and there's no good reason why Ada
couldn't be in the mix instead.

--
-- 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 to make Ada a dominant language

[David Bolen]

A bit of bad form to follow up on my own posting, but I previously wrote:

> Given that code written in other languages almost always tends to be
> block oriented and formatted (...)

Before too many people pick on it, clearly there are also languages
which dictate a non-block format, so I shouldn't have phrased the
above so generally.

--
-- 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 to make Ada a dominant language

[Russ Paielli]

Gary Lisyansky wrote:
> 
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0107292308.d1192fc@posting.google.com...
> > 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.
> 
> Ada is known to favour code reader over the code writer, while Python tends
> to be a typical "write only" language.

Sorry, but that's just baloney. You must be confusing Python with Perl.

> >
> > 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.
> 
> This makes whitespace the part of the language syntax. In practice, it's not
> convenient, and adds *extremely nasty* tab/space problems. In common, it's a
> bug generator.

Whitespace is already part of the language syntax. Don't believe me?
Take all the whitespace out of your programs and see if they still work.

> >
> > 2. Eliminate the requirement for a semicolon after each executable
> > statement, but allow semicolons for combining multiple statements on a
> > line, as in Python.
> 
> "Physical" line is not an element of Ada syntax. Writing statements in one
> line or several lines is purely the question of style which allows for more
> flexibility and readability. Changing this doesn't make any sense. In fact,
> suggestions 1 and 2 are in contradiction to the very idea of a free- form
> language.

If 99% of executable statements are on one line, it is ridiculous to
clutter every line with a semicolon.

> >
> > 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".
> 
> Exactly the same amount of typing. Only the reverse order of words that
> seems to be less readable.

The point is not the amount of typing. And I'll bet that the vast
majority of non-Ada-programmers think it is more, not less, readable.

Russ

Re: How to make Ada a dominant language

[Gary Lisyansky]

"Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
news:3B6557D2.DC2F9F2F@sneakemail.com...
> Gary Lisyansky wrote:
> > Ada is known to favour code reader over the code writer, while Python
tends
> > to be a typical "write only" language.
>
> Sorry, but that's just baloney. You must be confusing Python with Perl.

It's not a baloney at all. To list but some elegant features, absence of
parameter type information makes the source code very difficult to read.
Mandatory placement of statements in lines and indentation rule make the
thing even worse to read (a li'l hint: some procedures and nested compound
statements may not fit into the height of the scrollable viewport of your
editor:-)). Given variables are typeless, even the world's most  advanced
IDE won't give you a chance to understand what "someObject.doSomething"
really means and find the definition of doSomething(), for instance.
>
> > >
> > > 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.
> >
> > This makes whitespace the part of the language syntax. In practice, it's
not
> > convenient, and adds *extremely nasty* tab/space problems. In common,
it's a
> > bug generator.
>
> Whitespace is already part of the language syntax. Don't believe me?
> Take all the whitespace out of your programs and see if they still work.

Whitespace in well- designed languages is used as separator only. In Python
and other indentation- based languages it is effectively a keyword, and a
one without well- defined meaning. "Four whitespaces" may, depending on the
situation mean just the next statement in a block, or the end of a compound
statement, or may be used to distinguish between a method of a class and a
non- component function. What's that, programming using innuendoes?
Add here bugs like mis- indented statement that may keep the code still
formally valid but screwed up logically.
>
> > >
> > > 2. Eliminate the requirement for a semicolon after each executable
> > > statement, but allow semicolons for combining multiple statements on a
> > > line, as in Python.
> >
> > "Physical" line is not an element of Ada syntax. Writing statements in
one
> > line or several lines is purely the question of style which allows for
more
> > flexibility and readability. Changing this doesn't make any sense. In
fact,
> > suggestions 1 and 2 are in contradiction to the very idea of a free-
form
> > language.
>
> If 99% of executable statements are on one line, it is ridiculous to
> clutter every line with a semicolon.

99 /= 100. And, the ability to freely use whitespace to format the source
code for easy readability is quite valuable. Using ":" or ";" *inside* the
multiline statement is much weirder, it's used (except Python) mostly for
compatibility with advanced languages frequently called "street Basic".

>
> > >
> > > 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".
> >
> > Exactly the same amount of typing. Only the reverse order of words that
> > seems to be less readable.
>
> The point is not the amount of typing. And I'll bet that the vast
> majority of non-Ada-programmers think it is more, not less, readable.

The infamous if (a = b) is so widespread an error in C++ that many compilers
issue a warning when encounter this perfectly legal construct. It's because
even years of C++ programming can't erase natural human habit to use "=" as
equality operator, and not "==".

>
> Russ

Gary

Re: How to make Ada a dominant language

[Russ Paielli]

Gary Lisyansky wrote:
> 
> "Russ Paielli" <18k11tm001@sneakemail.com> wrote in message
> news:3B6557D2.DC2F9F2F@sneakemail.com...
> > Gary Lisyansky wrote:
> > > Ada is known to favour code reader over the code writer, while Python
> tends
> > > to be a typical "write only" language.
> >
> > Sorry, but that's just baloney. You must be confusing Python with Perl.
> 
> It's not a baloney at all. To list but some elegant features, absence of
> parameter type information makes the source code very difficult to read.
> Mandatory placement of statements in lines and indentation rule make the
> thing even worse to read (a li'l hint: some procedures and nested compound
> statements may not fit into the height of the scrollable viewport of your
> editor:-)). Given variables are typeless, even the world's most  advanced
> IDE won't give you a chance to understand what "someObject.doSomething"
> really means and find the definition of doSomething(), for instance.

I am obviously NOT suggesting for a second that Ada adopt Python's
untyped variables. Are you deliberately trying to distort what I am
proposing, or are you just completely failing to grasp it?

> > > >
> > > > 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.
> > >
> > > This makes whitespace the part of the language syntax. In practice, it's
> not
> > > convenient, and adds *extremely nasty* tab/space problems. In common,
> it's a
> > > bug generator.
> >
> > Whitespace is already part of the language syntax. Don't believe me?
> > Take all the whitespace out of your programs and see if they still work.
> 
> Whitespace in well- designed languages is used as separator only. In Python
> and other indentation- based languages it is effectively a keyword, and a
> one without well- defined meaning. "Four whitespaces" may, depending on the
> situation mean just the next statement in a block, or the end of a compound
> statement, or may be used to distinguish between a method of a class and a
> non- component function. What's that, programming using innuendoes?
> Add here bugs like mis- indented statement that may keep the code still
> formally valid but screwed up logically.

Would you call ";" a "keyword"?

As I wrote elsewhere, Python's use of indentation as logical structure
FORCES the programmer to use proper indentation structure, which is
completely in the Ada spirit of enforcing good practices (rather than
simply "allowing" them). More importantly, Python assures the reader of
the code that the logical structure is consistent with the indentation
structure.

<cut>

> The infamous if (a = b) is so widespread an error in C++ that many compilers
> issue a warning when encounter this perfectly legal construct. It's because
> even years of C++ programming can't erase natural human habit to use "=" as
> equality operator, and not "==".

Another red herring. What I am proposing has absolutely nothing to do
with this pitfall of C++.

Russ

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ Paielli <18k11tm001@sneakemail.com> wrote in message news:<3B6565D7.9C7407B9@sneakemail.com>...
> 
> Would you call ";" a "keyword"?
                               ^^^
Why border to put "?" after your question
                                        ^^^
("?" is deliberately omitted!) :)

Adrian Hoe
> 
> 
> Russ

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

Russ Paielli wrote:
> Gary Lisyansky wrote:
> > "Russ" <18k11tm001@sneakemail.com> wrote in message
...snip...
> > "Physical" line is not an element of Ada syntax. Writing statements in one
> > line or several lines is purely the question of style which allows for more
> > flexibility and readability. Changing this doesn't make any sense. In fact,
> > suggestions 1 and 2 are in contradiction to the very idea of a free- form
> > language.
> 
> If 99% of executable statements are on one line, it is ridiculous to
> clutter every line with a semicolon.

Sorry, nope, not rediculous. If you are auditing a piece of critical
software, as I expect happens with flight critical software, from a 
hardcopy, it is reassuring to know that the end of the statement is
right where that semicolon is. This confirms that there is not more
code that didn't get cut off on the line printer/photocopier/whatever.

Will anyone in the industry confirm or add to this? 

I know from my own experience, just from auditing some difficult C code 
in times past, that these "little things" can make quite helpful 
on hardcopy.

It can also be helpful when reading those example programs in books,
where the author has re-typed the code in by hand (why they don't use
cut and paste at least?), and the code is full of bugs. The semicolon
and other things that you consider unnecessary, can be quite helpful
in descerning what the author's true intent was.

> The point is not the amount of typing. And I'll bet that the vast
> majority of non-Ada-programmers think it is more, not less, readable.
> 
> Russ

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

Re: How to make Ada a dominant language

[Gerhard Häring]

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


The problem with "simple preprocessors" is that you don't get good error 
messages any more.

> Here are the syntax changes I propose:

[snip]

I like both Python and Ada. I use Ada syntax in Ada and Python syntax in 
Python. There are already preprocessors for Perl and C++ that translate 
from a Python-like syntax to Perl/C++ (search freshmeat).

The syntax of a programming language is something relatively 
superficial. I don't think that Ada's little popularity is causes by its 
syntax. I used to be a great Modula-2 fan and was immediatly familiar 
with Ada.

-- Gerhard

Re: How to make Ada a dominant language

[Gary Scott]

Note that most of the below changes would also make Ada look like
Fortran 95...

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

[AG]

"> Russ wrote:

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

That's an obvious contradiction in requirements: Semicolons no longer
terminate
a statement but they still combine statements? So what does separate one
statement
from the next? To elaborate: if you have some other scheme to identify the
statements
you don't need the semicolon at all, if you rely on it to join the
statements why not use
it for separation too?

Re: How to make Ada a dominant language

[Russ]

AG wrote:
> 
> "> Russ wrote:
> 
> > > 2. Eliminate the requirement for a semicolon after each executable
> > > statement, but allow semicolons for combining multiple statements on a
> > > line, as in Python.
> 
> That's an obvious contradiction in requirements: Semicolons no longer
> terminate
> a statement but they still combine statements? So what does separate one
> statement
> from the next? To elaborate: if you have some other scheme to identify the
> statements
> you don't need the semicolon at all, if you rely on it to join the
> statements why not use
> it for separation too?

Check out how Python and Fortran 95 do it. It is not a "contradiction in
requirements."

Russ

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

I can't leave this one alone... (but should)...

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

Ahem: "end label;" helps to insure that the programmer knows who's
"end" it is. It may be inconceivable that programmers have technical
problems like this, but it happens.

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

Blech. What are you going to do for long statements -- make us use 
backslashes at the end of the line or something (I am Python 
illiterate, and hope to stay that way.)

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

I am already ambidextrous : I can use = for C/C++ and := for Ada.

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

Blech. That'll make it look like IBM JCL ;-)

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

Again, I am ambidextrous : I can declare the C/C++ way, or the Ada way.
I see no need to change it.

> 6. Eliminate the "is" keyword.

Depending upon how you format your code, I find it allows a nice
line break at the right place if I want it ;-)

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

You really don't understand the use of "use" do you?

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

Eh? (I think "eh" was another language, wasn't it?)

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

Surely you jest.

> 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

The former is already well established with many millions of lines of
code written that way. I see no problem with it as it is. 

Don't quit your day job.

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

Re: How to make Ada a dominant language

[Russ Paielli]

"Warren W. Gay VE3WWG" wrote:
> 
> I can't leave this one alone... (but should)...

Yes, you should have. :)

> 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
> > 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.
> 
> Ahem: "end label;" helps to insure that the programmer knows who's
> "end" it is. It may be inconceivable that programmers have technical
> problems like this, but it happens.

That's a valid point.

> > 2. Eliminate the requirement for a semicolon after each executable
> > statement, but allow semicolons for combining multiple statements on a
> > line, as in Python.
> 
> Blech. What are you going to do for long statements -- make us use
> backslashes at the end of the line or something (I am Python
> illiterate, and hope to stay that way.)

Yes. Most statements take only one line, so you will have far fewer
"extensions" than single-line statements.

> > 3. Use "=" rather than ":=" for assignment, as in Python. (Use "=="
> > for equality testing if necessary to avoid confusion with assignment.)
> 
> I am already ambidextrous : I can use = for C/C++ and := for Ada.

I can too. I can also walk on all fours, but I would look like a fool if
I did it all the time, wouldn't I? So would you, I bet.

> > 4. Use "=" instead of "=>" for passing arguments by named association,
> > as in Python.
> 
> Blech. That'll make it look like IBM JCL ;-)

Not to me it won't, because I've never seen JCL.

> > 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".
> 
> Again, I am ambidextrous : I can declare the C/C++ way, or the Ada way.
> I see no need to change it.

I'll bet you can walk backwards too. Would you do it without complaining
if someone forced you to for the rest of your life?

> > 6. Eliminate the "is" keyword.
> 
> Depending upon how you format your code, I find it allows a nice
> line break at the right place if I want it ;-)
> 
> > 7. Let "use" imply "with" so the tops of files need not be cluttered
> > with both "with" and "use" for the same package.
> 
> You really don't understand the use of "use" do you?

I thought I did, but maybe not.

> > 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.
> 
> Eh? (I think "eh" was another language, wasn't it?)
> 
> > 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.
> 
> Surely you jest.

No, I don't. And please stop calling me Shirly.

> > 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
> 
> The former is already well established with many millions of lines of
> code written that way. I see no problem with it as it is.

I do.

> Don't quit your day job.

Quit yours.

Russ

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

Russ Paielli wrote:
> "Warren W. Gay VE3WWG" wrote:
> > I can't leave this one alone... (but should)...
> 
> Yes, you should have. :)

I can see that you are right on this one point.. 8-/

> > Russ wrote:
> > > 3. Use "=" rather than ":=" for assignment, as in Python. (Use "=="
> > > for equality testing if necessary to avoid confusion with assignment.)
> >
> > I am already ambidextrous : I can use = for C/C++ and := for Ada.
> 
> I can too. I can also walk on all fours, but I would look like a fool if
> I did it all the time, wouldn't I? So would you, I bet.

But we are not talking about walking on all fours are we? You've
mistaken that for "assembly language" and possibly "FORTRAN".

> > > 4. Use "=" instead of "=>" for passing arguments by named association,
> > > as in Python.
> >
> > Blech. That'll make it look like IBM JCL ;-)
> 
> Not to me it won't, because I've never seen JCL.

Lucky you.

> > > 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".
> >
> > Again, I am ambidextrous : I can declare the C/C++ way, or the Ada way.
> > I see no need to change it.
> 
> I'll bet you can walk backwards too. Would you do it without complaining
> if someone forced you to for the rest of your life?

Again, we're not talking about walking backwards, or on all fours. The difference
is as small as "yes" or "yep" or even, "yup".

> > > 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.
> >
> > Surely you jest.
> 
> No, I don't. And please stop calling me Shirly.

Surely, you didn't say that? ;-)

> > The former is already well established with many millions of lines of
> > code written that way. I see no problem with it as it is.
> 
> I do.
> 
> > Don't quit your day job.
> 
> Quit yours.

I'd love to!  Unfortunately, retirement is still a spec on the
horizon. ;-)

> Russ

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

Re: How to make Ada a dominant language

[Philip Anderson]

Russ Paielli wrote:
<snipped freely> 
> > Ahem: "end label;" helps to insure that the programmer knows who's
> > "end" it is. It may be inconceivable that programmers have technical
> > problems like this, but it happens.
> 
> That's a valid point.

Well, believe it or not a lot of thought did go into the design of Ada.


> Yes. Most statements take only one line, so you will have far fewer
> "extensions" than single-line statements.

I'm not actually convinced of that; eg a procedure call plus parameter
list is a statement which very rarely fits on one line (only with a
single parameter).


> > I am already ambidextrous : I can use = for C/C++ and := for Ada.
> 
> I can too. I can also walk on all fours, but I would look like a fool if
> I did it all the time, wouldn't I? So would you, I bet.

Look up "ambidextrous"; it means being equally capable, and I somehow
doubt whether you could walk as quickly or as far on four legs as two. 
Plenty of people here seem to have no problem being bilingual in Ada and
C, only you.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: How to make Ada a dominant language

[Keith Thompson]

18k11tm001@sneakemail.com (Russ) writes:
[...]
> 1. Eliminate the "end" keyword and make the indentation structure an
> inherent part of the syntax, as in Python.

I personally don't mind Python's use of indentation to indicate
program structure, but a lot of programmers despise it.  You propose
to alienate those programmers for no good reason, while making it
far less clear where a construct ends.

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

Ada is a free-form language.  Requiring a semicolon on each statement
eliminates the need for a special syntax for splitting a single
statement across multiple lines.

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

Assignment and equality testing are two different things.  They should
look different.

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

"Proc(Foo = Bar)" is already a valid Ada procedure call; it passes the
value True if Foo and Bar are equal, False if they aren't.

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

It's backward only if you're accustomed to declarations that put the
type first.  For anyone accustomed to Ada-style (or Pascal-style)
declarations, they look perfectly natural.  Anyone else should be able
to get used to it quickly enough.

> 6. Eliminate the "is" keyword.

Right.  Just imagine the man-years that have been wasted typing those
two letters.

How would you declare a derived type ("type Foo is new Bar;")?

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

"with" can be applied to any library unit.  "use" can be applied to
any package.  Not all library units are packges, and not all packages
are library units.

>     count: integer := 0;  -- old syntax
> 
>     integer: count = 0  -- new syntax

They're both about equally clear; the old syntax has the advantage of
being what we've been using in Ada for the past 20 years or so.

As someone else pointed out, all programming languages are artificial.
There are many choices to make in designing a programming language;
often neither possible choice is any more or less "natural" than the
other.

Seriously, how many programmers do you know who (1) dislike Ada
because of its syntax, *and* (2) would become Ada enthusiasts if it
were changed in accordance with your suggestions?  I suggest there are
far fewer than you think.

I would also suggest that accusing those who disagree with you of
being unintelligent is just about the worst possible way to convince
anyone that you're right.  After all, I'm always right, but there are
plenty of intelligent people who disagree with me.  8-)}

-- 
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 to make Ada a dominant language

[Philip Anderson]

Keith Thompson wrote:
> 
> 18k11tm001@sneakemail.com (Russ) writes:
<snip>
> > 4. Use "=" instead of "=>" for passing arguments by named association,
> > as in Python.
> 
> "Proc(Foo = Bar)" is already a valid Ada procedure call; it passes the
> value True if Foo and Bar are equal, False if they aren't.

But Russ would replace that with "Proc(Foo == Bar)", so no ambiguity :-)


Consider the following (in NewAda, Ada in comments):

Integer : Foo  -- Foo : Integer;
Integer : Bar  -- Bar : Integer;

procedure Proc (Integer in : Foo)
-- procedure Proc (Foo : in Integer);

procedure Proc (Boolean in : A)
-- procedure Proc (A : in Boolean);


Proc (Foo = Bar)   -- Proc (Foo => Bar);
Proc (Foo == Bar)  -- Proc (Foo = Bar);
Proc (Foo >= Bar)  -- Proc (Foo >= Bar);


"Proc(Foo = Bar)" would certainly confuse existing Ada programmers, but
Ada is potentially confusing too.  I'd always write something like "Proc
(A => (Foo = Bar))" to show that the "Foo = Bar" is an expression


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: How to make Ada a dominant language

[Stanley R. Allen]

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.
> 
> Here are the syntax changes I propose:
> 
> 1. 

Russ:

Your proposals lead me to believe that you have yet to spend much time
programming with Ada.  By your own admission, you are 'new to Ada'.
I recommend getting more familiar with the language, perhaps absorbing
the Rationale and/or one of the deeper textbooks, and working on some
medium-sized programming projects.  You may find that once you get deeper
with the language, you won't feel so disappointed with the syntax.

Also, it would help if you learn more about the history of Ada.  You will find
that multiple attempts have been made in a number of directions to try to
increase Ada's popularity.  Ada's been around for over 18 years, and better
reasons for its successes and setbacks have been repeatedly discussed in
this and other publicly available forums.

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

Re: How to make Ada a dominant language

[Russ]

Well, I guess I touched some raw nerves with my proposal to clean up
Ada's syntax. I certainly appreciate the feedback.

I have come to the conclusion that my first item (eliminating the "end"
keyword and making the indentation structure an inherent part of the
syntax, as in Python) is NOT a good idea after all. The "end" lines
really do help with readability, particularly for long procedures that
end on a different page than they started.

However, I still stand by the other items in my proposal. I think
semicolons should be essentially eliminated, and I think "=" should be
used for assignment and named association. I also still think the
declaration syntax should be reversed. By the way, someone correctly
pointed out that what I am proposing has a lot in common with Fortran
95.

Furthermore, I think the idea of having another "dialect" of Ada is an
innovative concept with real potential. If you reject it out hand, you
simply have a closed mind.

Most of the replies I received on this thread were very reasonable. A
recurring theme, however, was that syntax is trivial and not worth
discussing. I understand that the syntax is not the most important
aspect of a language, but that doesn't mean it is not worth discussing
or improving.

I have a colleague who started programming in Fortran way back in the
sixties (maybe even the fifties). He is a master algorithm developer and
programmer. His code is meticulously correct, efficient, and minimal.
When I introduced him to C and C++ several years ago, he was amazed that
he had to clutter his code with all those semicolons and constantly put
up with the compiler's nagging when one is left out. He adapted, of
course, but his initial reaction was right. All those semicolons are
nothing more than a lot of noise. They are litter in your code, and if
you never minded them at all, then your code is probably filled with
lots of other litter too. If so, I hope it is not being used in any
safety-critical systems.

Russ Paielli

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ <18k11tm001@sneakemail.com> wrote in message news:<3B676974.C80C72E5@sneakemail.com>...
> Well, I guess I touched some raw nerves with my proposal to clean up
> Ada's syntax. I certainly appreciate the feedback.
> 
> I have come to the conclusion that my first item (eliminating the "end"
> keyword and making the indentation structure an inherent part of the
> syntax, as in Python) is NOT a good idea after all. The "end" lines
> really do help with readability, particularly for long procedures that
> end on a different page than they started.
> 
> However, I still stand by the other items in my proposal. I think
> semicolons should be essentially eliminated, 

I still think a semicolon is nice It serves as a punctuation
indicating an end of the statement and the beginning of next How does
this paragraph looks like to you Taking away punctuations from written
text makes reading difficult Certainly people will likely to make
mistake while reading This is an analogy example to your proposition
to remove semicolon from Ada

I think punctuation is nice. It makes life easier! And so is emoticons
:)

Adrian Hoe

> Russ Paielli

Re: How to make Ada a dominant language

[Russ]

Adrian Hoe wrote:
> 
> Russ <18k11tm001@sneakemail.com> wrote in message news:<3B676974.C80C72E5@sneakemail.com>...
> > Well, I guess I touched some raw nerves with my proposal to clean up
> > Ada's syntax. I certainly appreciate the feedback.
> >
> > I have come to the conclusion that my first item (eliminating the "end"
> > keyword and making the indentation structure an inherent part of the
> > syntax, as in Python) is NOT a good idea after all. The "end" lines
> > really do help with readability, particularly for long procedures that
> > end on a different page than they started.
> >
> > However, I still stand by the other items in my proposal. I think
> > semicolons should be essentially eliminated,
> 
> I still think a semicolon is nice It serves as a punctuation
> indicating an end of the statement and the beginning of next How does
> this paragraph looks like to you Taking away punctuations from written
> text makes reading difficult Certainly people will likely to make
> mistake while reading This is an analogy example to your proposition
> to remove semicolon from Ada

But if almost every sentence were on a separate line, you wouldn't need
punctuation to mark their end. Besides that; I think; too many;
punctuation marks; make text; look cluttered; What; do; you; think?; ;')

Russ

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ <18k11tm001@sneakemail.com> wrote in message news:<3B67B0BC.F51C4CB4@sneakemail.com>...
> Adrian Hoe wrote:
> > 
> > Russ <18k11tm001@sneakemail.com> wrote in message news:<3B676974.C80C72E5@sneakemail.com>...
> > > Well, I guess I touched some raw nerves with my proposal to clean up
> > > Ada's syntax. I certainly appreciate the feedback.
> > >
> > > I have come to the conclusion that my first item (eliminating the "end"
> > > keyword and making the indentation structure an inherent part of the
> > > syntax, as in Python) is NOT a good idea after all. The "end" lines
> > > really do help with readability, particularly for long procedures that
> > > end on a different page than they started.
> > >
> > > However, I still stand by the other items in my proposal. I think
> > > semicolons should be essentially eliminated,
> > 
> > I still think a semicolon is nice It serves as a punctuation
> > indicating an end of the statement and the beginning of next How does
> > this paragraph looks like to you Taking away punctuations from written
> > text makes reading difficult Certainly people will likely to make
> > mistake while reading This is an analogy example to your proposition
> > to remove semicolon from Ada
> 
> But if almost every sentence were on a separate line, you wouldn't need
> punctuation to mark their end. Besides that; I think; too many;
> punctuation marks; make text; look cluttered; What; do; you; think?; ;')


Of course if you put semicolons like you did, they look cluttered.
Punctuation should be used correctly and purposefully at the right
place. In Ada, the purpose of semicolon is to mark the end of a
statement. Of course, it is illegal to put a semicolon immediately
after if ... then, not like C where it denotes null statement.

C:

if a == 0 then;   /* Is perfectly legal */

But in Ada:

if a = 0 then;    -- Illegal

According to your proposition:

if a = 0 then
   a = 1
   b = 2
   c = 3
end if

can lead to many errors, for instance:

if a = 0 then
   a = 1 b = 2
   c=3
end if

But with Ada:

if a = 0 then
   a = 1;
   b = 2;
   c = 3;
end if;

And this is much clearer because at a glance, you see the semicolons
and you see end of statements!

Adrian Hoe

> Russ

Re: How to make Ada a dominant language

[Russ]

Adrian Hoe wrote:
> 
> Russ <18k11tm001@sneakemail.com> wrote in message news:<3B67B0BC.F51C4CB4@sneakemail.com>...
> > Adrian Hoe wrote:
> > >
> > > Russ <18k11tm001@sneakemail.com> wrote in message news:<3B676974.C80C72E5@sneakemail.com>...
> > > > Well, I guess I touched some raw nerves with my proposal to clean up
> > > > Ada's syntax. I certainly appreciate the feedback.
> > > >
> > > > I have come to the conclusion that my first item (eliminating the "end"
> > > > keyword and making the indentation structure an inherent part of the
> > > > syntax, as in Python) is NOT a good idea after all. The "end" lines
> > > > really do help with readability, particularly for long procedures that
> > > > end on a different page than they started.
> > > >
> > > > However, I still stand by the other items in my proposal. I think
> > > > semicolons should be essentially eliminated,
> > >
> > > I still think a semicolon is nice It serves as a punctuation
> > > indicating an end of the statement and the beginning of next How does
> > > this paragraph looks like to you Taking away punctuations from written
> > > text makes reading difficult Certainly people will likely to make
> > > mistake while reading This is an analogy example to your proposition
> > > to remove semicolon from Ada
> >
> > But if almost every sentence were on a separate line, you wouldn't need
> > punctuation to mark their end. Besides that; I think; too many;
> > punctuation marks; make text; look cluttered; What; do; you; think?; ;')
> 
> Of course if you put semicolons like you did, they look cluttered.
> Punctuation should be used correctly and purposefully at the right
> place. In Ada, the purpose of semicolon is to mark the end of a
> statement. Of course, it is illegal to put a semicolon immediately
> after if ... then, not like C where it denotes null statement.
> 
> C:
> 
> if a == 0 then;   /* Is perfectly legal */
> 
> But in Ada:
> 
> if a = 0 then;    -- Illegal
> 
> According to your proposition:
> 
> if a = 0 then
>    a = 1
>    b = 2
>    c = 3
> end if
> 
> can lead to many errors, for instance:
> 
> if a = 0 then
>    a = 1 b = 2
>    c=3
> end if
> 
> But with Ada:
> 
> if a = 0 then
>    a = 1;
>    b = 2;
>    c = 3;
> end if;
> 
> And this is much clearer because at a glance, you see the semicolons
> and you see end of statements!

Check out how Fortran 95 does it. They don't seem to have the problem
you are referring to.

Russ

Re: How to make Ada a dominant language

[Gary Scott]

Russ wrote:
> 
> Adrian Hoe wrote:
> >
> > Russ <18k11tm001@sneakemail.com> wrote in message news:<3B67B0BC.F51C4CB4@sneakemail.com>...
> > > Adrian Hoe wrote:
> > > >
> > According to your proposition:
> >
> > if a = 0 then
> >    a = 1
> >    b = 2
> >    c = 3
> > end if
> >
> > can lead to many errors, for instance:
> >
> > if a = 0 then
> >    a = 1 b = 2
> >    c=3
> > end if
> >
> > But with Ada:
> >
> > if a = 0 then
> >    a = 1;
> >    b = 2;
> >    c = 3;
> > end if;
> >
> > And this is much clearer because at a glance, you see the semicolons
> > and you see end of statements!
> 
> Check out how Fortran 95 does it. They don't seem to have the problem
> you are referring to.
> 
Fortran 95 simply recognizes logical end of record as the same as end of
statement unless a special continuation character is used.  Consecutive
statements may be separated by ";".  I think that this method was
mentioned indirectly in several previous posts and was thought to be "a
bad thing" because it isn't "true" free-form format.
> Russ

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ <18k11tm001@sneakemail.com> wrote in message news:<3B676974.C80C72E5@sneakemail.com>...
> 
> Furthermore, I think the idea of having another "dialect" of Ada is an
> innovative concept with real potential. If you reject it out hand, you
> simply have a closed mind.

Resistance is futile... (I can't remember which movies... Anyone?)

Adrian Hoe


> Russ Paielli

Re: How to make Ada a dominant language

[Marin David Condic]

Maybe "The Borg" - Star Trek TNG?

In addition, to comment on Russ's comment about closed minds. I don't think
anybody has any objection to your developing any dialect of Ada you want to
and seeing if it has anything useful to offer. Others have done the same in
the past in order to get features into Ada that didn't exist. (I recall
someone had a version of Ada that included OOP features on top of Ada-83 -
anybody remember that?) It just won't find much traction here because there
are lots of good reasons why the syntax is what it is.

The problem is it will not likely gain much acceptance in the Ada community
because a) People like the fact that there is One-And-Only-One Ada, b) we
don't believe there is anything seriously "broke" about the syntax, c) we
perceive the complaints you have as probably coming from a perspective of
"This isn't what I'm used to, so I want to change it to look more like what
I know" rather than being some well founded criticism of the syntax based on
some kind of evidence of a real problem (Is there a real problem? Can you
point to some kind of evidence that programs are routinely bungled or
frequently contain syntax errors because of ":=" or ";" being parts of the
language? Anything beyond "It doesn't look comfortable to me?")  d) the
syntax of Ada was carefully designed by people with a high level of
experience and background in language design and the decisions were not made
lightly, on a whim or because of one individual's "preference" that it look
a certain way.

You should know that there is a *lot* of collective experience in this
group - especially with developing safety-critical systems. Being critical
of Ada is O.K., but if you start getting dozens of (expert) opinions here
about why something is generally a good/bad idea, you might want to give a
little credit to the sources.

    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."
        --  G.K. Chesterton

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/


"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:9ff447f2.0107312313.666dea54@posting.google.com...
> Russ <18k11tm001@sneakemail.com> wrote in message
news:<3B676974.C80C72E5@sneakemail.com>...
> >
> > Furthermore, I think the idea of having another "dialect" of Ada is an
> > innovative concept with real potential. If you reject it out hand, you
> > simply have a closed mind.
>
> Resistance is futile... (I can't remember which movies... Anyone?)
>
> Adrian Hoe
>
>
> > Russ Paielli

Re: How to make Ada a dominant language

[Russ]

Marin David Condic wrote:
> 
> Maybe "The Borg" - Star Trek TNG?
> 
> In addition, to comment on Russ's comment about closed minds. I don't think
> anybody has any objection to your developing any dialect of Ada you want to
> and seeing if it has anything useful to offer. Others have done the same in
> the past in order to get features into Ada that didn't exist. (I recall
> someone had a version of Ada that included OOP features on top of Ada-83 -
> anybody remember that?) It just won't find much traction here because there
> are lots of good reasons why the syntax is what it is.
> 
> The problem is it will not likely gain much acceptance in the Ada community
> because a) People like the fact that there is One-And-Only-One Ada, b) we
> don't believe there is anything seriously "broke" about the syntax, c) we
> perceive the complaints you have as probably coming from a perspective of
> "This isn't what I'm used to, so I want to change it to look more like what
> I know" rather than being some well founded criticism of the syntax based on
> some kind of evidence of a real problem (Is there a real problem? Can you

No, it's not that I want something I'm "used to." On the contrary, I
want to get RID of something I'm tired of: the semicolons in C/C++.

> point to some kind of evidence that programs are routinely bungled or
> frequently contain syntax errors because of ":=" or ";" being parts of the
> language? Anything beyond "It doesn't look comfortable to me?")  d) the
> syntax of Ada was carefully designed by people with a high level of
> experience and background in language design and the decisions were not made
> lightly, on a whim or because of one individual's "preference" that it look
> a certain way.

It would be interesting to add up all the time programmers spend going
back and putting in semicolons and recompiling after the compiler
catches their omission. I'll bet it's over a tenth of a percent of the
programming time (of C/C++ and Ada programmers). Not much, eh? Let's
see, if 100,000 programmers are using those languages, that's 100
man-years per year flushed right down the toilet.

But the issue is deeper than that. The unnecessary delays and annoyances
disturb a programmers continuity. Why do you think "scripting" languages
are so much better for rapid prototyping? The compile cycle is
eliminated. Eliminating semicolons will not eliminate the compile cycle,
but it will make it much less annoying, thereby making Ada more
convenient for another whole class of applications.

> You should know that there is a *lot* of collective experience in this
> group - especially with developing safety-critical systems. Being critical
> of Ada is O.K., but if you start getting dozens of (expert) opinions here
> about why something is generally a good/bad idea, you might want to give a
> little credit to the sources.

If the Ada community is unwilling to adapt, that is certainly their
perogative. With all due respect, however, I find most of the objections
to my proposal to be unconvincing. On the one hand, most people seem to
be saying that syntax is unimportant, but on the other hand it is
sacrosanct and not to be messed with. Then I get the folks telling me
that simple concepts used in Fortran 95 won't work or will cause some
kind of insidious problem. It's almost as if someone were standing at
the airport and explaining why airplanes can't possibly fly, and even if
they could they would be useless.

>     "Having an open mind is nothing. The object of opening the mind, as
>     of opening the mouth, is to shut it again on something solid."
>         --  G.K. Chesterton

I agree. Do you?

Russ

Re: How to make Ada a dominant language

[Ted Dennison]

In article <3B6842AD.1C56ECBE@sneakemail.com>, Russ says...
>
>It would be interesting to add up all the time programmers spend going
>back and putting in semicolons and recompiling after the compiler
>catches their omission. I'll bet it's over a tenth of a percent of the
>programming time (of C/C++ and Ada programmers). Not much, eh? Let's

You'd get zippo out of me. I had lots of trouble with them in Pascal (which had
sillier rules for them, if I remember right). But I can't remember getting one
of those errors out of an Ada compiler in *years*. The closest I can think of is
the occasions that I accidently put an *extra* one in at the end of a parameter
spec list (more likely, when I delete the last paramter, and forget to remove
the semi on the previous line). But that is *really* rare.

If you have problems with this, I'd wadger you are just unused to the Algol
family of languages. That will pass with time.

But even if this *were* an issue (which its not), I don't think you'd get much
of a rise out of anyone here. Most of us Ada folk are way more concerned about
the time spent debugging our code than we are about the time we spend placating
the compiler (or typing it up, for that matter). There's just no comparison
between the two where effort expended is concerned. You'd have much more luck
saying something like, "here's a *new* check that Ada compilers should be forced
to do for all code". For instance, you almost have me with your "mandatory
indention checking" argument...

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

Re: Semicolons (was: How to make Ada a dominant language)

[Warren W. Gay VE3WWG]

Russ wrote:
> Marin David Condic wrote:
> > Maybe "The Borg" - Star Trek TNG?
...snip...
> No, it's not that I want something I'm "used to." On the contrary, I
> want to get RID of something I'm tired of: the semicolons in C/C++.
> 
> > point to some kind of evidence that programs are routinely bungled or
> > frequently contain syntax errors because of ":=" or ";" being parts of the
> > language? Anything beyond "It doesn't look comfortable to me?")  d) the
> > syntax of Ada was carefully designed by people with a high level of
> > experience and background in language design and the decisions were not made
> > lightly, on a whim or because of one individual's "preference" that it look
> > a certain way.
> 
> It would be interesting to add up all the time programmers spend going
> back and putting in semicolons and recompiling after the compiler
> catches their omission. I'll bet it's over a tenth of a percent of the
> programming time (of C/C++ and Ada programmers). Not much, eh? Let's
> see, if 100,000 programmers are using those languages, that's 100
> man-years per year flushed right down the toilet.

I think your experience with semicolons is unique. I rarely, if ever,
miss a semi-colon. In fact, I cannot ever remember having to go back
and put one in. If I did, it might have been way back when I was 
learning to program in "B" (until C later became available to me).
However, even then, it seemed so natural to me -- much more so than
trying to remember where the periods should go in COBOL!

I did a stint in PL/I and it's various dialects, and again -- it seemed
very very natural. If I were to design a language, I'd make certain it
used a semicolon ;-)  (even the smileys like it)

In fact, if we are realistic here, I'll bet that this thread has easily
cost more in human time (let alone USENET CPU cycles), than you'll ever
save in the change you're proposing. ;-)

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

Re: How to make Ada a dominant language

[Stefan Nobis]

Russ <18k11tm001@sneakemail.com> writes:

> It would be interesting to add up all the time programmers spend going
> back and putting in semicolons and recompiling after the compiler

Just use a good editor. I never press return to go to the next line, but i
press ; instead. My editor then knows the line is complete and jumps to the
next line automagically. So to eliminate semikola out of the language makes me
type return instead of ;. Where is the difference -- in one case i press one
key and in the other case i press another key.

So if you have problems pressing one of the two keys, why should these
problems go away if you have to press another key? And if you have to press
both you should just use a better editor (that's what you asked others when
they complained about tabs/spaces).

> perogative. With all due respect, however, I find most of the objections
> to my proposal to be unconvincing. On the one hand, most people seem to

I find you complete proposal unconvincing. So what?

There are many decisions you have to make if you are designing a language. But
if a language is wide spread you should not mess around with fundamental
things like the syntax. That's why C++ is based on the syntax of C (Stroustrup
knew all the problems with C and it's syntax, but he also knew that his new
language would only be accepted by many developers, if the changed on
fundamental things like syntax and basic semantics are not too big).

The question if blockbuilding is done with whitespaces or explicit commands
and if the end of statements are denoted by a whitespace or another character
is a really minor problem. Both ways have their pros and cons.

-- 
Until the next mail...,
Stefan.

Re: How to make Ada a dominant language

[AG]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:3B6842AD.1C56ECBE@sneakemail.com...

> No, it's not that I want something I'm "used to." On the contrary, I
> want to get RID of something I'm tired of: the semicolons in C/C++.

Assembler then? (Various Assemblers may use semicolons too but at
least not for that purpose). They also don't typically like the free-form
text arrangment...

> It would be interesting to add up all the time programmers spend going
> back and putting in semicolons and recompiling after the compiler
> catches their omission. I'll bet it's over a tenth of a percent of the
> programming time (of C/C++ and Ada programmers).

Someone else already posted that missing semicolons is extremely rare,
after all they are there to punctuate what should be punctuated in any case
so they come naturally. But, what about the time spent on going back and
*removing* the extra semicolons I put in in some other compiler that doesn't
like them? And to put the matter in perspective: 0.1% of a (say) 40 hour
working week means 144 seconds per week. I suggest you would have
a very hard time selling that as a major savings to management. And never
mind the phony trick of doing the nation-wide or world-wide totals - in that
case you would also need to convince the nation-wide or world-wide
congregation of managers. 144 seconds eh? What about a minute or two
you spend every time you reboot <<some OS>>?

> But the issue is deeper than that. The unnecessary delays and annoyances
> disturb a programmers continuity. Why do you think "scripting" languages
> are so much better for rapid prototyping?

One thing that often gets forgotten is the meaning of the word "prototype".
It sort of suggests that this isn't a real product - just some sort of a
preliminary
scetch to be thrown out and replaced with a *real* thing. You wouldn't
really
like to drive a prototype car would you? Or fly a prototype plane? Not
unless
that happens to be your job I suppose.

> Eliminating semicolons will not eliminate the compile cycle,
> but it will make it much less annoying, thereby making Ada more
> convenient for another whole class of applications.

It will just move some percentage of the "missing semicolon" errors to the
later
run-time/testing stages. Much more annoying, isn't it?

Re: How to make Ada a dominant language

[Barry Kelly]

In article <3B6842AD.1C56ECBE@sneakemail.com>
	Russ <18k11tm001@sneakemail.com> wrote:

> It would be interesting to add up all the time programmers spend going
> back and putting in semicolons and recompiling after the compiler
> catches their omission. I'll bet it's over a tenth of a percent of the
> programming time (of C/C++ and Ada programmers). Not much, eh?

You haven't done much Ada/Pascal/C/C++ programming, have you?

Happens about once a month. And that's pushing it.

-- Barry

-- 
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re: How to make Ada a dominant language

[Adrian Hoe]

Russ <18k11tm001@sneakemail.com> wrote in message news:<3B676974.C80C72E5@sneakemail.com>...
> Most of the replies I received on this thread were very reasonable. A
> recurring theme, however, was that syntax is trivial and not worth
> discussing. I understand that the syntax is not the most important
> aspect of a language, but that doesn't mean it is not worth discussing
> or improving.

Errr. Mistake! Syntax and lexical are the fundamental building blocks
of any languages, natural or computer.

Adrian Hoe


> Russ Paielli

Re: How to make Ada a dominant language

[Preben Randhol]

On Tue, 31 Jul 2001 19:29:08 -0700, Russ wrote:

> I have a colleague who started programming in Fortran way back in the
> sixties (maybe even the fifties). He is a master algorithm developer and

[...]

> All those semicolons are
> nothing more than a lot of noise. They are litter in your code, and if
> you never minded them at all, then your code is probably filled with
> lots of other litter too. If so, I hope it is not being used in any
> safety-critical systems.

Clearly you don't know what you talk about.

Which is more readable (taken from a program I develop) :

Your proposal (note if one use an editor that has wrapping on one will
screw up the code as it will put this _one_ line on several)

    Button_Callback.Connect (Gui_Result.Practise_More_Button, "clicked", Button_Callback.To_Marshaller (On_Practise_More_Button_Clicked'Access))

As you can see it is almost impossible to fit it within the horisontal
viewport of the editor, and it is not an exception.

Ada way with ;

     Button_Callback.Connect (Gui_Result.Practise_More_Button, 
                              "clicked", 
                              Button_Callback.To_Marshaller 
                                 (On_Practise_More_Button_Clicked'Access));

Of course if you talk about Fortran 77 this cannot be coded and the
variable would have really meaningful names like:

   PRXMBTN -- Practise_More_Button

FORTRAN 77 is probably one of the worser languages (apart from Perl and
flavours) to make readable code in because of the limitations on the
number of characters one can use for a variable name and that hopelessly
idiotic automatic type casting which produces loads and loads of errors
that are very hard to find. I really hope that F77 isn't used in any
safety-critical systems.

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

[David Gillon]

Russ wrote:
> Furthermore, I think the idea of having another "dialect" of Ada is an
> innovative concept with real potential. If you reject it out hand, you
> simply have a closed mind.

Allowing a dialect of Ada is directly contrary to one of Ada's
fundamental design concepts. Rejecting the idea isn't the knee-jerk idea
you seem to think. Look up the concepts behind the Ada Compiler
Validation suite.

> All those semicolons are
> nothing more than a lot of noise. They are litter in your code, and if
> you never minded them at all, then your code is probably filled with
> lots of other litter too. If so, I hope it is not being used in any
> safety-critical systems.

If you don't recognise the utility of semicolons then you may need to
rethink what is desirable in safety-critical code. One thing
safety-critical code can't afford is ambiguity as that may conceal an
error. The semicolon says emphatically 'I want to end this line here, it
is complete'. I'd much rather a syntactically significant semicolon than
syntactically significant white space....

-- 

David Gillon

Re: How to make Ada a dominant language

[Russ]

David Gillon wrote:
> 
> Russ wrote:
> > Furthermore, I think the idea of having another "dialect" of Ada is an
> > innovative concept with real potential. If you reject it out hand, you
> > simply have a closed mind.
> 
> Allowing a dialect of Ada is directly contrary to one of Ada's
> fundamental design concepts. Rejecting the idea isn't the knee-jerk idea
> you seem to think. Look up the concepts behind the Ada Compiler
> Validation suite.

I would agree with that philosophy if the dialects were incompatible,
but the dialect I am proposing could be automatically translated back
and forth with standard Ada95.

Russ

Re: How to make Ada a dominant language

[Warren W. Gay VE3WWG]

Russ wrote:
> David Gillon wrote:
> > Russ wrote:
> > > Furthermore, I think the idea of having another "dialect" of Ada is an
> > > innovative concept with real potential. If you reject it out hand, you
> > > simply have a closed mind.
> >
> > Allowing a dialect of Ada is directly contrary to one of Ada's
> > fundamental design concepts. Rejecting the idea isn't the knee-jerk idea
> > you seem to think. Look up the concepts behind the Ada Compiler
> > Validation suite.
> 
> I would agree with that philosophy if the dialects were incompatible,
> but the dialect I am proposing could be automatically translated back
> and forth with standard Ada95.
> 
> Russ

This means that you want to make Ada95 and intermediate language; I don't
think that would be received too well; This adds a software layer that
adds complexity; Complexity not only breeds bugs; It breeds contempt;

Just my $0.02 worth;

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

Re: How to make Ada a dominant language

[Scott Ingram]

Russ wrote:
> 
> Well, I guess I touched some raw nerves with my proposal to clean up
> Ada's syntax. I certainly appreciate the feedback.
> 

I appreciate your enthusiasm for popularizing Ada, and I don't think
you touched any "raw nerves."  Most of your respondents in this thread
have been using Ada for some time, and understand the rationale behind
the syntax that Ada employs.  There are some very interesting and
valid criticisms that can be made with regard to the language, but
the syntax is way below the radar screen for most of us.

(snip)

> 
> However, I still stand by the other items in my proposal. I think
> semicolons should be essentially eliminated, and I think "=" should be
> used for assignment and named association. I also still think the
> declaration syntax should be reversed. By the way, someone correctly
> pointed out that what I am proposing has a lot in common with Fortran
> 95.

I personally find these suggestions abhorrent.  I find the current
syntax
a relief after working with other imperative languages.  It doesn't 
happen often, but I have used conditional tests that are sufficiently
complex that they are easier to read if broken into several lines, and
the semicolon marking the end of the statement is very handy for marking
the end of a collection of thoughts.  As for the declaration order and
assignment operator--they happen to match the way I think very closely,
changing them would twist my brain in knots! (Which is the state its in
most of the time...)

> 
> Furthermore, I think the idea of having another "dialect" of Ada is an
> innovative concept with real potential. If you reject it out hand, you
> simply have a closed mind.

There are two other "dialects" of Ada that have proven very successful
in their targeted markets. PL/SQL as an adjunct to Oracle in the
database market, and VHDL in programmable logic devices.  What's weird
is how many people fail to connect these with Ada.

> 
> Most of the replies I received on this thread were very reasonable. A
> recurring theme, however, was that syntax is trivial and not worth
> discussing. I understand that the syntax is not the most important
> aspect of a language, but that doesn't mean it is not worth discussing
> or improving.

Agreed, but this actually is not the proper forum.  As might be expected
for such a formal language, there are working groups and committees who
evaluate such proposals for inclusion in the standard.

> 
> I have a colleague who started programming in Fortran way back in the
> sixties (maybe even the fifties). He is a master algorithm developer and
> programmer. His code is meticulously correct, efficient, and minimal.
> When I introduced him to C and C++ several years ago, he was amazed that
> he had to clutter his code with all those semicolons and constantly put
> up with the compiler's nagging when one is left out. He adapted, of
> course, but his initial reaction was right. All those semicolons are
> nothing more than a lot of noise. They are litter in your code, and if
> you never minded them at all, then your code is probably filled with
> lots of other litter too. If so, I hope it is not being used in any
> safety-critical systems.
> 
> Russ Paielli

Major difference of opinion here:  those semicolons are not "litter,"
but rather like the firestops in the wall of your house they provide
an added margin of safety by compartmentalizing thoughts as the
firestops compartmentalize the spaces in the structure.

As far as Ada's "popularity" goes, I think it fair to argue that it
is more popular now than at any time in its history.  Although some
shops have moved away from its use now the dreaded mandate has been
rescinded, there is a lot more traffic on c.l.a from new users who
don't carry baggage from that era.

-- 
Scott Ingram
Vice-Chair, Baltimore SIGAda
System Development and Operational Support Group
Johns Hopkins University Applied Physics Laboratory

Re: How to make Ada a dominant language

[Russ]

Scott Ingram wrote:
> 
<cut>

> > I have a colleague who started programming in Fortran way back in the
> > sixties (maybe even the fifties). He is a master algorithm developer and
> > programmer. His code is meticulously correct, efficient, and minimal.
> > When I introduced him to C and C++ several years ago, he was amazed that
> > he had to clutter his code with all those semicolons and constantly put
> > up with the compiler's nagging when one is left out. He adapted, of
> > course, but his initial reaction was right. All those semicolons are
> > nothing more than a lot of noise. They are litter in your code, and if
> > you never minded them at all, then your code is probably filled with
> > lots of other litter too. If so, I hope it is not being used in any
> > safety-critical systems.
> >
> > Russ Paielli
> 
> Major difference of opinion here:  those semicolons are not "litter,"
> but rather like the firestops in the wall of your house they provide
> an added margin of safety by compartmentalizing thoughts as the
> firestops compartmentalize the spaces in the structure.

Please take a look at how Fortran 95 handles source lines. Now, if you
don't like it, that is your perogative, but please don't give me any
garbage about how Ada's way is any better. It isn't. The two styles are
logically equivalent, but the Fortran style is cleaner and less likely
to generate annoying and useless compilation errors.

You'll probably be happy to know that I'm about ready to give up on this
thing (at least for now). I can't believe all the ridiculous
justifications I get for stupid syntax.

> As far as Ada's "popularity" goes, I think it fair to argue that it
> is more popular now than at any time in its history.  Although some
> shops have moved away from its use now the dreaded mandate has been
> rescinded, there is a lot more traffic on c.l.a from new users who
> don't carry baggage from that era.

Ya, right. It will be used for a good long time, just like HAL and
Jovial. Actually, I wish the best for Ada, but I am not encouraged.

Russ

Re: How to make Ada a dominant language

[Leif Roar Moldskred]

Russ <18k11tm001@sneakemail.com> wrote:

> Please take a look at how Fortran 95 handles source lines. Now, if you
> don't like it, that is your perogative, but please don't give me any
> garbage about how Ada's way is any better. It isn't. The two styles are
> logically equivalent, but the Fortran style is cleaner and less likely
> to generate annoying and useless compilation errors.

Err... He's not allowed to claim that Ada's way is the better, but
you're allowed to claim that Fortran95's way is better?

Really. It's one thing to be opinionated, but you're verging on
fanatical.

> You'll probably be happy to know that I'm about ready to give up on this
> thing (at least for now). I can't believe all the ridiculous
> justifications I get for stupid syntax.

I've followed all of this thread, and I can't see I've seen anyone
make justifications for the syntax. Some people have said "A
divergence of the Ada standard would be worse than any gain in
syntax.", and some have said "I don't agree with you that the syntax
is stupid." Neither point of view is a justification.


-- 
Leif Roar Moldskred
closet Adaphile

Re: How to make Ada a dominant language

[Lao Xiao Hai]

This has been an entertaining discussion.    There are several points that
Russ makes that deserve some careful response.    Some earlier messages
covered some of the points.   Most of those responses dealt with the
syntactic issues.   I choose to respond to his "with" / "use" observation
since this is at the heart of Ada's design.   As a prefatory
remark, we note that the default of every Ada construct intended to
be safe.  One can take a default of safe and relax it to a construct that
is less safe.  It is more difficult in a language where the default is
unsafe,
to promote a construct to one that is more safe.

Chapter Eight of the Ada Language Reference Manual has a set of
carefully delineated rules regarding the difference between scope and
visibility.   In my experience, more programmers have more difficulties
with Ada because of these rules than any other part of the language.   Yet,
we see that most programmers choose not to study this issue until their
frustration emboldens them to dash their mouse to the floor and smash it
in rage.

The language design for Ada is unique in its differentiation between scope
and visibility.   More recent language designs, for example the namespace
option of C++, have adopted a somewhat anemic version of this feature,
but Ada remains more powerful in this respect.

An #include statement in some popular languages has  the approximate
semantics of an Ada with/use combination.   I say approximate because
there are some additional rules that make Ada a tad more reliable.

Consider an electrician who decides to string some wire through your house.
It is typical that the wire will have insulation over most of its length and

some well-defined interfaces at other points, usually the terminal points.
A
similar kind of thing is done in many other engineering designs.   A
pipeline
is built with specific locations where one can open or close it for
extracting
the content, or for adding some content.

A "with" clause, in Ada, is somewhat analogous to stringing the wire through

the house.   We keep the insulation intact to reduce the probability of
burning
down the house.   All the electricity we want is streaming through that
wire,
but our access to it is carefully controlled.   If we want access to the
current,
we can cut a little piece from the insulation and tap into it with another
wire,
but we take care to replace the insulation for the splice when we are done.

An #include, as defined for most languages, does not have a concept of
insulation.
Every feature is directly exposed, all the time.  Some very interesting
errors can
occur in large-scale software.   Since an Ada context clause ("with") makes
nothing
directly visible, the software engineer has responsibility to identify where
to
remove the insulation, how to remove it, and precisely how much to remove.

A visibility clause ("use") makes everything visible.  This is the
equivalent of
removing all the insulation at one time.   Good Ada design suggests that
this
may be too much exposure, for a variety of reasons.   Consequently, we
employ
one of several mechanisms as alternatives to the global visibility clause.
As engineers, we should always be interested in techniques for reducing
risk.

The somewhat tedious technical discussion that follows is guaranteed to bore

experienced Ada programmers, but may be of some use to those new to the
language such as Mr. Paielli.

Given a package specification,

            package P1 is
                type T1 is ...
                type T2 is ...
                procedure Process (Q_Data : in out T1);
                procedure Process (R_Data : in out T2);
           private
               -- private declarations
           end P1;

we have several approaches available to controlling visibility and reducing
ambiguity.

The global visibility clause:

           with P1;
           use  P1;
           procedure Test_1 is
               X : T1;
               Y : T2;
               Z :  T2;
           begin
               if y = Z then
                  Process(X);
               end if;
           end Test_1;

For this little program, there is probably no difficulty.  However, one
might
want to further disambiguate by ensuring the right call is made.  For
example,

             Process (Q_Data => X);

would be a better choice for the parameter association.    As a point of
interest,
it is appropriate to use a different symbol than assignment for this since
the
semantics of association and assignment are quite different.

Another way to control visibility might be as follows:

           with P1;
           procedure Test_2 is
               use type P1.T2;
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
           begin
               if Y = Z then
                  P1.Process(Q_Data => X);
               end if;
           end Test_2;

In this example, we have used the more restrictive version of the
visibility clause ("use type") so the equality operator will be
directly visible.   The problem with this is that, even though we
are now required to use dot notation for all operation calls, we
also make all the other infix operators visible.  For more rigorous
designs, we might want to avoid this approach.   Often, the
directly visibility of infix operators makes it easier to write some
code, but it also fails to restrict the writer to those options that,
from an engineering perspective, make sense.

Sometimes a programmer will localize the visibility clause.

           with P1;
           procedure Test_3 is
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
           begin
               declare
                   use P1;  -- or better yet, use type P1.T2
               begin
                    if Y = Z then
                         P1.Process(Q_Data => X);
                    end if;
               end;
           end Test_3;

This does have the benefit of localizing the visibility clause.   However, a

well-crafted paper by Geoff Mendal once analyzed this option and found
it lacking in the rigor or disambiguity necessary for consistent
reliability.

Most Ada development organizations I deal with prefer the following:

           with P1;
           procedure Test_4 is
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
               function "=" (L, R : P1.T2) return Boolean renames P1."="'
           begin
                    if Y = Z then
                         P1.Process(Q_Data => X);
                    end if;
           end Test_4;

In this example, we have made the equality operator directly visible through

renaming.   While this may seem somewhat bizzare to the newcomer, it
actually
has much to recommend it, from an engineering point-of-view.   This becomes
especially important when one wants to really restrict the set of operations

immediately available to a maintenance programmer in some distant time.

Another approach I have seen useful is a compromise.   I realize Tucker Taft

will leap all over me for continuing to suggest this alternative, but I find
some
organizations are using it with some success, and a minimum of risk.   This
is
the proactive approach of a nested infix operators package.  I personally
prefer
it to the "use type" clause.   I also prefer this to the creation of a child
library
unit, although that approach has much to recommend it.

           package P1 is
                type T1 is ...
                type T2 is ...
                procedure Process (Q_Data : in out T1);
                procedure Process (R_Data : in out T2);
                package Operators is
                    function "=" (L, R : P1.T2) return Boolean
                                                          renames P1."=");
                end Operators;
           private
               -- private declarations
           end P1;

Now we can have a use clause on the nested package only.

           with P1;
           procedure Test_5 is
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
               use P1.Operators;
           begin
                    if Y = Z then
                         P1.Process(Q_Data => X);
                    end if;
           end Test_5;

In this case, the use clause applies only to the nested package.

I hope this clarifies a few issues related to the scope and visibility
features of Ada.   Certainly, there is more to be studied before one
can fully apprehend all of this topic.   However, it is, to my mind,
equally as important as the type safety that causes such a fuss.  This
aspect of Ada, along with type safety, is the foundation of the Ada
software engineering model.   We could change a lot of syntactic
rules, alter the reserved word list, and lots of other things, but we
would not want to relax the reliability of the language by abandoning
this important feature.

I hope this helps, Mr. Paielli.

Regards,

Richard Riehle

----------------------------------------------------------------------------------



Russ wrote:

> Well, I guess I touched some raw nerves with my proposal to clean up
> Ada's syntax. I certainly appreciate the feedback.
>
> I have come to the conclusion that my first item (eliminating the "end"
> keyword and making the indentation structure an inherent part of the
> syntax, as in Python) is NOT a good idea after all. The "end" lines
> really do help with readability, particularly for long procedures that
> end on a different page than they started.
>
> However, I still stand by the other items in my proposal. I think
> semicolons should be essentially eliminated, and I think "=" should be
> used for assignment and named association. I also still think the
> declaration syntax should be reversed. By the way, someone correctly
> pointed out that what I am proposing has a lot in common with Fortran
> 95.
>
> Furthermore, I think the idea of having another "dialect" of Ada is an
> innovative concept with real potential. If you reject it out hand, you
> simply have a closed mind.
>
> Most of the replies I received on this thread were very reasonable. A
> recurring theme, however, was that syntax is trivial and not worth
> discussing. I understand that the syntax is not the most important
> aspect of a language, but that doesn't mean it is not worth discussing
> or improving.
>
> I have a colleague who started programming in Fortran way back in the
> sixties (maybe even the fifties). He is a master algorithm developer and
> programmer. His code is meticulously correct, efficient, and minimal.
> When I introduced him to C and C++ several years ago, he was amazed that
> he had to clutter his code with all those semicolons and constantly put
> up with the compiler's nagging when one is left out. He adapted, of
> course, but his initial reaction was right. All those semicolons are
> nothing more than a lot of noise. They are litter in your code, and if
> you never minded them at all, then your code is probably filled with
> lots of other litter too. If so, I hope it is not being used in any
> safety-critical systems.
>
> Russ Paielli

Re: How to make Ada a dominant language

[Darren New]

Wow. OK. That's way over the top, compared to the kinds of care I take,
and I'm more careful than most programmers I know. Where does one learn
such stuff? Or is it a matter of getting involved at the entry level in
a project where such things are necessary?

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
"You probably noticed you can't breath underwater. Hence the tank."
   -- PADI instruction manual, page 107.

Re: How to make Ada a dominant language

[Russ P.]

Lao Xiao Hai wrote:
> 
> This has been an entertaining discussion.    There are several points that
> Russ makes that deserve some careful response.    Some earlier messages
> covered some of the points.   Most of those responses dealt with the
> syntactic issues.   I choose to respond to his "with" / "use" observation
> since this is at the heart of Ada's design.   As a prefatory
> remark, we note that the default of every Ada construct intended to
> be safe.  One can take a default of safe and relax it to a construct that
> is less safe.  It is more difficult in a language where the default is
> unsafe,
> to promote a construct to one that is more safe.

That's all very interesting, and I appreciate the explanation. However,
I did not make any statement whatsoever regarding the advisibility of
using "use" or the proper way to use it. The fact is that if you put
"use SomePackage" at the top of a file, it doesn't make sense unless you
have already put "with SomePackage" (or am I still missing something?).
All I am saying is that you shouldn't need the "with" statement if it is
already implied. Now, if that causes some logical problems, then I guess
it can't be done.

As for the other syntactical suggestions I made, I am still 100%
convinced that the Fortran/Python syntax for assignment, named
association, and lack of semicolons is better and cleaner than Ada
syntax. If you think that bad syntax should simply be left alone for the
sake of stability, than I disagree, but that's a judgment call. However,
if you've talked yourself into believing that the basic Ada syntax is
somehow safer or more precise, then you've talked yourself into
believing nonsense.

Ada is a great language for safety-critical systems--no doubt about it.
However, I think it could also be better than it is for rapid
prototyping if the syntax is cleaned up. Oh, I realize that other
languages will always be better than Ada for rapid prototyping, but that
is beside the point. What if I am doing rapid prototyping of algorithms
for a system that will eventually be safety-critical? For obvious
reasons, I may be better off doing the prototyping and the final design
in the same language. That's what I actually want to do, folks.

Russ P.
http://RussP.org

Re: How to make Ada a dominant language

[Lao Xiao Hai]

"Russ P." wrote:

> That's all very interesting, and I appreciate the explanation. However,
> I did not make any statement whatsoever regarding the advisibility of
> using "use" or the proper way to use it. The fact is that if you put
> "use SomePackage" at the top of a file, it doesn't make sense unless you
> have already put "with SomePackage" (or am I still missing something?).
> All I am saying is that you shouldn't need the "with" statement if it is
> already implied. Now, if that causes some logical problems, then I guess
> it can't be done.

Let me see if I can summarize.  A context clause, "with",  puts the services
of a library unit in scope.   A visibility clause, "use", makes all those
services directly visible.   In a sense, the visibility clause is similar to
the "import" clause in Java where the equivalent of a context clause is,
indeed, implied.

For production code, we discourage the visibility clause.  However, it is
still necessary to put selected library units in scope.   That selection is
enabled through the context clause, "with."   Ada never permits anything
to be implied.   Each construct is explicit and intentional.    There is a
very sound engineering principle in this model, but it does not always
jump to the eye.

As to your comments regarding syntatic changes, I did not respond to them
in my original post.   In my own programming practice, the current syntax
seems to work quite well so I have no complaint about it.   I do understand
that those who migrate to Ada from another language will sometimes find
the syntax unnatural.   When I migrated from Assembler to Fortran, all my
code looked as if I were coding Fortran in Assembler style.  When I had
to do some projects in COBOL, my COBOL code looked like Fortran.  When
I did my first project in C, my code looked like Assembler, and I actually found

C to be quite annoying.   As I gained more experience using a greater variety
of programming languages, I developed some preferences, but I also found
that I had little trouble simply adopting the syntax of each new language.

Adopting the structural differences of a new language was quite another matter.
On first encountering Ada, I found it confusing,  verbose, full of what I
thought
were unnecessary and extraneous constructs, and generally not my idea of a
great programming language.   Once I had some good experience with it, actually
writing code and designing programs, I changed my mind.  At present, I place
it quite high, syntax included, in my preference for programming languages. I
also like Eiffel, which has no C-family syntactic baggage, as well as Smalltalk.

These things are a matter of personal taste, as noted earlier by Mr. Falis.   So
far,
I have rarely encountered a programmer who was so set in the ways of one
language
that she/he found Ada syntax that annoying, after using it for a while.   I
respectfully
disagree with the proposition that language syntax has very much to do with
Ada's
lack of popularity.

Certainly the C-family syntax, borrowed heavily by Java, Python, C++, C#. Perl,
and Ruby, is more widely used.   That does not make it better.   The popularity
of this syntax does not originate in a search for better syntax.   It derives
from
a tendency to follow the "path of least resistance,"  common in human nature.

So I would consider changes in Ada syntax, at this juncture, to be a bad idea,
if
for no other reason than the many millions of lines of code, the many changes to

compiler design, and the many Ada programmers who are quite satisfied with it
as it is.   This is not to mention that some of the changes you have suggested
are
in the language to satisfy its underlying goal of reliability.   Many of those
syntactic
artifacts are in place to tip-off the compiler to a potential inconsistency in
design,
poor programming reasoning, or sloppy coding practice.   In some cases, they are

the key to the compiler's being able to detect unconfirmable constructs.

You may object to this line of reasoning, but I see no good reason to make
changes
in the language syntax unless those changes contribute to the underlying goal of

the language:  the ability to build more robust compilers that detect errors as
early
in the development process as possible.

I do appreciate your starting this dialogue since we all benefit from an
occasional
bit of criticism and questions about the rationale for the language design.

Thanks,

Richard Riehle

Re: How to make Ada a dominant language

[Mike Silva]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0107292308.d1192fc@posting.google.com>...
> 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:

<snipped...>

Alright, personal testimony time...

I discovered Ada a few years ago, coming from two decades of C and
later C++.  It never occurred to me that Ada should look like C (or
Python, or ???), and I don't understand why some people make such an
issue about it.  I don't find the syntax awkward or klunky at all.  I
find that I enjoy reading Ada source code, kind of like looking at the
innards of a fine machine.  Ada source has a nice flow to it -- it
doesn't cram too much symbolic information into too little space. 
When I go back to some well-packed C source I get annoyed that I have
to concentrate so much harder to pick apart the pieces.  In the end it
takes me more time to comprehend the fewer characters.  (OK, I do
still miss [], but it's a very small price indeed.)

All this concern about typing a few extra characters makes no sense to
me.  My guess is that it's just part of the larger "no time to think,
gotta start coding!" mentality of so many programmers (I know, I've
still not completely shaken the virus myself).  Sometimes I think we'd
have a great boost in software quality if we'd just force programmers
to type only with their index fingers.

Mike

Re: How to make Ada a dominant language

[Russ]

Mike Silva wrote:
> 
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0107292308.d1192fc@posting.google.com>...
> > 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:
> 
> <snipped...>
> 
> Alright, personal testimony time...
> 
> I discovered Ada a few years ago, coming from two decades of C and
> later C++.  It never occurred to me that Ada should look like C (or
> Python, or ???), and I don't understand why some people make such an
> issue about it.  I don't find the syntax awkward or klunky at all.  I
> find that I enjoy reading Ada source code, kind of like looking at the
> innards of a fine machine.  Ada source has a nice flow to it -- it
> doesn't cram too much symbolic information into too little space.
> When I go back to some well-packed C source I get annoyed that I have
> to concentrate so much harder to pick apart the pieces.  In the end it
> takes me more time to comprehend the fewer characters.  (OK, I do
> still miss [], but it's a very small price indeed.)
> 
> All this concern about typing a few extra characters makes no sense to
> me.  My guess is that it's just part of the larger "no time to think,
> gotta start coding!" mentality of so many programmers (I know, I've
> still not completely shaken the virus myself).  Sometimes I think we'd
> have a great boost in software quality if we'd just force programmers
> to type only with their index fingers.
> 
> Mike

Like so many of the other posters here, you are missing the point. I am
not suggesting for a minute that C has a better syntax. Nor am I
suggesting that the amount of typing is the issue. The issue is
extraneous clutter in the code. 99% of semicolons are extraneous
clutter. Many languages, such as Python and Fortran 95 manage just fine
without them. And, for Pete's sake, NO I am not suggesting that Fortran
95 is better overall than Ada!

Russ

Re: How to make Ada a dominant language

[Ed Falis]

Russ wrote:

> Like so many of the other posters here, you are missing the point. I am
> not suggesting for a minute that C has a better syntax. Nor am I
> suggesting that the amount of typing is the issue. The issue is
> extraneous clutter in the code. 99% of semicolons are extraneous
> clutter. Many languages, such as Python and Fortran 95 manage just fine
> without them. And, for Pete's sake, NO I am not suggesting that Fortran
> 95 is better overall than Ada!
> 
> Russ

Actually, Eiffel takes some interesting middle ground between Ada and
what you propose syntactically.  Semicolons are optional except when
multiple statements appear on the same line.  The subprogram and "block"
syntax is somewhat more streamlined.

But it stills uses := for assignment, which you probably won't like ;-)

You might want to check it out.  It's my #2 language. 

As far as Ada goes, I think the syntax is one of its major features, and
one of the things that Ichbiah was rightly proud of.  Can't argue taste,
I suppose.

- Ed

Re: How to make Ada a dominant language

[AG]

"Ed Falis" <efalis@mediaone.net> wrote in message
news:3B678C55.6C06C6C4@mediaone.net...
> Russ wrote:
>
> > Like so many of the other posters here, you are missing the point. I am
> > not suggesting for a minute that C has a better syntax. Nor am I
> > suggesting that the amount of typing is the issue. The issue is
> > extraneous clutter in the code. 99% of semicolons are extraneous
> > clutter. Many languages, such as Python and Fortran 95 manage just fine
> > without them. And, for Pete's sake, NO I am not suggesting that Fortran
> > 95 is better overall than Ada!
> >
> > Russ

Just to point out the obvious: Do you realise that ALL the punctuation marks
in the above paragraph are a total "extraneous clutter"? To prove the point,
just remove all of the marks and see if you can still read it. I could. It
may be
[quite] a bit harder but possible. So, why do you personally use the style
you
argue against?

Re: How to make Ada a dominant language

[raj]

On 30 Jul 2001 00:08:56 -0700, 18k11tm001@sneakemail.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
>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:

Why not just use a modern language instead ?

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

[Beard, Frank]

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

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

Frank

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


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

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

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