* How to make Ada a dominant language @ 2001-07-30 7:08 Russ 2001-07-30 8:36 ` Preben Randhol ` (9 more replies) 0 siblings, 10 replies; 875+ messages in thread From: Russ @ 2001-07-30 7:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ @ 2001-07-30 8:36 ` Preben Randhol 2001-07-30 12:41 ` Russ Paielli 2001-07-30 8:36 ` How to make Ada a dominant language Gary Lisyansky ` (8 subsequent siblings) 9 siblings, 1 reply; 875+ messages in thread From: Preben Randhol @ 2001-07-30 8:36 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 8:36 ` Preben Randhol @ 2001-07-30 12:41 ` Russ Paielli 2001-07-30 12:52 ` Preben Randhol ` (4 more replies) 0 siblings, 5 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-30 12:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:41 ` Russ Paielli @ 2001-07-30 12:52 ` Preben Randhol 2001-07-30 13:24 ` Russ Paielli ` (2 more replies) 2001-07-30 12:52 ` Gary Lisyansky ` (3 subsequent siblings) 4 siblings, 3 replies; 875+ messages in thread From: Preben Randhol @ 2001-07-30 12:52 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:52 ` Preben Randhol @ 2001-07-30 13:24 ` Russ Paielli 2001-07-30 15:47 ` Preben Randhol ` (2 more replies) 2001-07-30 15:38 ` Darren New 2001-07-31 8:31 ` Florian Weimer 2 siblings, 3 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-30 13:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:24 ` Russ Paielli @ 2001-07-30 15:47 ` Preben Randhol 2001-07-30 23:13 ` Gary Scott 2001-07-31 1:07 ` Adrian Hoe 2 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-07-30 15:47 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:24 ` Russ Paielli 2001-07-30 15:47 ` Preben Randhol @ 2001-07-30 23:13 ` Gary Scott 2001-07-31 1:07 ` Adrian Hoe 2 siblings, 0 replies; 875+ messages in thread From: Gary Scott @ 2001-07-30 23:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:24 ` Russ Paielli 2001-07-30 15:47 ` Preben Randhol 2001-07-30 23:13 ` Gary Scott @ 2001-07-31 1:07 ` Adrian Hoe 2 siblings, 0 replies; 875+ messages in thread From: Adrian Hoe @ 2001-07-31 1:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:52 ` Preben Randhol 2001-07-30 13:24 ` Russ Paielli @ 2001-07-30 15:38 ` Darren New 2001-07-31 8:31 ` Florian Weimer 2 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-07-30 15:38 UTC (permalink / raw) > > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:52 ` Preben Randhol 2001-07-30 13:24 ` Russ Paielli 2001-07-30 15:38 ` Darren New @ 2001-07-31 8:31 ` Florian Weimer 2 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-07-31 8:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:41 ` Russ Paielli 2001-07-30 12:52 ` Preben Randhol @ 2001-07-30 12:52 ` Gary Lisyansky 2001-07-30 13:38 ` Russ Paielli ` (3 more replies) 2001-07-30 18:22 ` Stefan Nobis ` (2 subsequent siblings) 4 siblings, 4 replies; 875+ messages in thread From: Gary Lisyansky @ 2001-07-30 12:52 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:52 ` Gary Lisyansky @ 2001-07-30 13:38 ` Russ Paielli 2001-07-30 13:43 ` Gary Lisyansky 2001-07-31 9:32 ` Philip Anderson ` (2 subsequent siblings) 3 siblings, 1 reply; 875+ messages in thread From: Russ Paielli @ 2001-07-30 13:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:38 ` Russ Paielli @ 2001-07-30 13:43 ` Gary Lisyansky 2001-07-30 15:08 ` Larry Kilgallen 0 siblings, 1 reply; 875+ messages in thread From: Gary Lisyansky @ 2001-07-30 13:43 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:43 ` Gary Lisyansky @ 2001-07-30 15:08 ` Larry Kilgallen 2001-07-30 15:02 ` Russ Paielli 0 siblings, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-07-30 15:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:08 ` Larry Kilgallen @ 2001-07-30 15:02 ` Russ Paielli 2001-07-30 15:52 ` Preben Randhol ` (6 more replies) 0 siblings, 7 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-30 15:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:02 ` Russ Paielli @ 2001-07-30 15:52 ` Preben Randhol 2001-07-30 17:19 ` Darren New 2001-07-30 16:21 ` Larry Kilgallen ` (5 subsequent siblings) 6 siblings, 1 reply; 875+ messages in thread From: Preben Randhol @ 2001-07-30 15:52 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:52 ` Preben Randhol @ 2001-07-30 17:19 ` Darren New 2001-07-31 7:35 ` Preben Randhol 2001-08-02 1:36 ` David Starner 0 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-07-30 17:19 UTC (permalink / raw) > «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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:19 ` Darren New @ 2001-07-31 7:35 ` Preben Randhol 2001-08-02 1:36 ` David Starner 1 sibling, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-07-31 7:35 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:19 ` Darren New 2001-07-31 7:35 ` Preben Randhol @ 2001-08-02 1:36 ` David Starner 2001-08-02 8:01 ` Larry Kilgallen ` (4 more replies) 1 sibling, 5 replies; 875+ messages in thread From: David Starner @ 2001-08-02 1:36 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 1:36 ` David Starner @ 2001-08-02 8:01 ` Larry Kilgallen 2001-08-02 8:11 ` David Starner 2001-08-02 14:47 ` Ted Dennison ` (3 subsequent siblings) 4 siblings, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 8:01 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 8:01 ` Larry Kilgallen @ 2001-08-02 8:11 ` David Starner 2001-08-02 12:11 ` Larry Kilgallen 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-02 8:11 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 8:11 ` David Starner @ 2001-08-02 12:11 ` Larry Kilgallen 0 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 12:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 1:36 ` David Starner 2001-08-02 8:01 ` Larry Kilgallen @ 2001-08-02 14:47 ` Ted Dennison 2001-08-02 16:10 ` Darren New 2001-08-02 16:09 ` Darren New ` (2 subsequent siblings) 4 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-02 14:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 14:47 ` Ted Dennison @ 2001-08-02 16:10 ` Darren New 2001-08-02 19:30 ` Larry Kilgallen 2001-08-02 20:52 ` Larry Kilgallen 0 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-08-02 16:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 16:10 ` Darren New @ 2001-08-02 19:30 ` Larry Kilgallen 2001-08-02 19:04 ` Darren New 2001-08-02 20:52 ` Larry Kilgallen 1 sibling, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 19:30 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 19:30 ` Larry Kilgallen @ 2001-08-02 19:04 ` Darren New 0 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-02 19:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 16:10 ` Darren New 2001-08-02 19:30 ` Larry Kilgallen @ 2001-08-02 20:52 ` Larry Kilgallen 1 sibling, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 20:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 1:36 ` David Starner 2001-08-02 8:01 ` Larry Kilgallen 2001-08-02 14:47 ` Ted Dennison @ 2001-08-02 16:09 ` Darren New 2001-08-02 23:39 ` bruns 2001-08-03 3:40 ` Larry Kilgallen 4 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-02 16:09 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 1:36 ` David Starner ` (2 preceding siblings ...) 2001-08-02 16:09 ` Darren New @ 2001-08-02 23:39 ` bruns 2001-08-03 7:28 ` Pascal Obry 2001-08-03 13:59 ` Marin David Condic 2001-08-03 3:40 ` Larry Kilgallen 4 siblings, 2 replies; 875+ messages in thread From: bruns @ 2001-08-02 23:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 23:39 ` bruns @ 2001-08-03 7:28 ` Pascal Obry 2001-08-03 18:53 ` Lao Xiao Hai 2001-08-03 13:59 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Pascal Obry @ 2001-08-03 7:28 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-03 7:28 ` Pascal Obry @ 2001-08-03 18:53 ` Lao Xiao Hai 0 siblings, 0 replies; 875+ messages in thread From: Lao Xiao Hai @ 2001-08-03 18:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 23:39 ` bruns 2001-08-03 7:28 ` Pascal Obry @ 2001-08-03 13:59 ` Marin David Condic 1 sibling, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-03 13:59 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 1:36 ` David Starner ` (3 preceding siblings ...) 2001-08-02 23:39 ` bruns @ 2001-08-03 3:40 ` Larry Kilgallen 4 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-03 3:40 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:02 ` Russ Paielli 2001-07-30 15:52 ` Preben Randhol @ 2001-07-30 16:21 ` Larry Kilgallen 2001-07-30 16:19 ` Russ Paielli 2001-07-31 3:06 ` Warren W. Gay VE3WWG 2001-07-30 17:19 ` Pascal Obry ` (4 subsequent siblings) 6 siblings, 2 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-07-30 16:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:21 ` Larry Kilgallen @ 2001-07-30 16:19 ` Russ Paielli 2001-07-30 16:33 ` Marin David Condic 2001-07-30 18:33 ` Stefan Nobis 2001-07-31 3:06 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-30 16:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:19 ` Russ Paielli @ 2001-07-30 16:33 ` Marin David Condic 2001-07-30 18:33 ` Stefan Nobis 1 sibling, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-07-30 16:33 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:19 ` Russ Paielli 2001-07-30 16:33 ` Marin David Condic @ 2001-07-30 18:33 ` Stefan Nobis 2001-07-30 21:26 ` Milan Mancel 1 sibling, 1 reply; 875+ messages in thread From: Stefan Nobis @ 2001-07-30 18:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 18:33 ` Stefan Nobis @ 2001-07-30 21:26 ` Milan Mancel 2001-07-31 3:37 ` Russ Paielli 2001-07-31 14:37 ` Ted Dennison 0 siblings, 2 replies; 875+ messages in thread From: Milan Mancel @ 2001-07-30 21:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 21:26 ` Milan Mancel @ 2001-07-31 3:37 ` Russ Paielli 2001-07-31 20:36 ` Milan Mancel 2001-07-31 14:37 ` Ted Dennison 1 sibling, 1 reply; 875+ messages in thread From: Russ Paielli @ 2001-07-31 3:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:37 ` Russ Paielli @ 2001-07-31 20:36 ` Milan Mancel 0 siblings, 0 replies; 875+ messages in thread From: Milan Mancel @ 2001-07-31 20:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 21:26 ` Milan Mancel 2001-07-31 3:37 ` Russ Paielli @ 2001-07-31 14:37 ` Ted Dennison 2001-07-31 14:56 ` Gary Lisyansky ` (3 more replies) 1 sibling, 4 replies; 875+ messages in thread From: Ted Dennison @ 2001-07-31 14:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 14:37 ` Ted Dennison @ 2001-07-31 14:56 ` Gary Lisyansky 2001-07-31 15:07 ` Marin David Condic ` (2 subsequent siblings) 3 siblings, 0 replies; 875+ messages in thread From: Gary Lisyansky @ 2001-07-31 14:56 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 14:37 ` Ted Dennison 2001-07-31 14:56 ` Gary Lisyansky @ 2001-07-31 15:07 ` Marin David Condic 2001-08-01 0:54 ` David Bolen 2001-08-01 9:11 ` Milan Mancel 3 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-07-31 15:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 14:37 ` Ted Dennison 2001-07-31 14:56 ` Gary Lisyansky 2001-07-31 15:07 ` Marin David Condic @ 2001-08-01 0:54 ` David Bolen 2001-08-01 13:17 ` Ted Dennison 2001-08-01 9:11 ` Milan Mancel 3 siblings, 1 reply; 875+ messages in thread From: David Bolen @ 2001-08-01 0:54 UTC (permalink / raw) 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 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 0:54 ` David Bolen @ 2001-08-01 13:17 ` Ted Dennison 2001-08-01 22:15 ` David Bolen 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-01 13:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 13:17 ` Ted Dennison @ 2001-08-01 22:15 ` David Bolen 0 siblings, 0 replies; 875+ messages in thread From: David Bolen @ 2001-08-01 22:15 UTC (permalink / raw) 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 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 14:37 ` Ted Dennison ` (2 preceding siblings ...) 2001-08-01 0:54 ` David Bolen @ 2001-08-01 9:11 ` Milan Mancel 2001-08-01 12:06 ` Larry Hazel ` (2 more replies) 3 siblings, 3 replies; 875+ messages in thread From: Milan Mancel @ 2001-08-01 9:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 9:11 ` Milan Mancel @ 2001-08-01 12:06 ` Larry Hazel 2001-08-01 13:41 ` Marin David Condic 2001-08-01 13:41 ` Ted Dennison 2001-08-01 13:28 ` Ted Dennison 2001-08-01 15:17 ` Scott Ingram 2 siblings, 2 replies; 875+ messages in thread From: Larry Hazel @ 2001-08-01 12:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 12:06 ` Larry Hazel @ 2001-08-01 13:41 ` Marin David Condic 2001-08-01 15:55 ` Larry Hazel 2001-08-01 13:41 ` Ted Dennison 1 sibling, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-01 13:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 13:41 ` Marin David Condic @ 2001-08-01 15:55 ` Larry Hazel 2001-08-01 16:56 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Larry Hazel @ 2001-08-01 15:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 15:55 ` Larry Hazel @ 2001-08-01 16:56 ` Marin David Condic 2001-08-01 19:18 ` Ed Falis 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-01 16:56 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 16:56 ` Marin David Condic @ 2001-08-01 19:18 ` Ed Falis 0 siblings, 0 replies; 875+ messages in thread From: Ed Falis @ 2001-08-01 19:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 12:06 ` Larry Hazel 2001-08-01 13:41 ` Marin David Condic @ 2001-08-01 13:41 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-01 13:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 9:11 ` Milan Mancel 2001-08-01 12:06 ` Larry Hazel @ 2001-08-01 13:28 ` Ted Dennison 2001-08-01 15:17 ` Scott Ingram 2 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-01 13:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 9:11 ` Milan Mancel 2001-08-01 12:06 ` Larry Hazel 2001-08-01 13:28 ` Ted Dennison @ 2001-08-01 15:17 ` Scott Ingram 2 siblings, 0 replies; 875+ messages in thread From: Scott Ingram @ 2001-08-01 15:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:21 ` Larry Kilgallen 2001-07-30 16:19 ` Russ Paielli @ 2001-07-31 3:06 ` Warren W. Gay VE3WWG 2001-07-31 4:10 ` Russ Paielli 1 sibling, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 3:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:06 ` Warren W. Gay VE3WWG @ 2001-07-31 4:10 ` Russ Paielli 2001-07-31 5:05 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Russ Paielli @ 2001-07-31 4:10 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 4:10 ` Russ Paielli @ 2001-07-31 5:05 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 5:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:02 ` Russ Paielli 2001-07-30 15:52 ` Preben Randhol 2001-07-30 16:21 ` Larry Kilgallen @ 2001-07-30 17:19 ` Pascal Obry 2001-07-31 3:46 ` Russ Paielli 2001-07-30 17:33 ` Brian Rogoff ` (3 subsequent siblings) 6 siblings, 1 reply; 875+ messages in thread From: Pascal Obry @ 2001-07-30 17:19 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:19 ` Pascal Obry @ 2001-07-31 3:46 ` Russ Paielli 2001-07-31 5:08 ` Warren W. Gay VE3WWG ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-31 3:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:46 ` Russ Paielli @ 2001-07-31 5:08 ` Warren W. Gay VE3WWG 2001-07-31 7:09 ` Pascal Obry 2001-07-31 14:17 ` Marin David Condic 2 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 5:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:46 ` Russ Paielli 2001-07-31 5:08 ` Warren W. Gay VE3WWG @ 2001-07-31 7:09 ` Pascal Obry 2001-07-31 14:17 ` Marin David Condic 2 siblings, 0 replies; 875+ messages in thread From: Pascal Obry @ 2001-07-31 7:09 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:46 ` Russ Paielli 2001-07-31 5:08 ` Warren W. Gay VE3WWG 2001-07-31 7:09 ` Pascal Obry @ 2001-07-31 14:17 ` Marin David Condic 2 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-07-31 14:17 UTC (permalink / raw) 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? > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:02 ` Russ Paielli ` (2 preceding siblings ...) 2001-07-30 17:19 ` Pascal Obry @ 2001-07-30 17:33 ` Brian Rogoff 2001-07-31 4:01 ` Russ Paielli 2001-07-30 17:51 ` file13 ` (2 subsequent siblings) 6 siblings, 1 reply; 875+ messages in thread From: Brian Rogoff @ 2001-07-30 17:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:33 ` Brian Rogoff @ 2001-07-31 4:01 ` Russ Paielli 2001-07-31 17:31 ` Brian Rogoff 0 siblings, 1 reply; 875+ messages in thread From: Russ Paielli @ 2001-07-31 4:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 4:01 ` Russ Paielli @ 2001-07-31 17:31 ` Brian Rogoff 0 siblings, 0 replies; 875+ messages in thread From: Brian Rogoff @ 2001-07-31 17:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:02 ` Russ Paielli ` (3 preceding siblings ...) 2001-07-30 17:33 ` Brian Rogoff @ 2001-07-30 17:51 ` file13 2001-07-31 14:51 ` Ted Dennison 2001-07-30 22:35 ` Attributes of a development which require Ada (Was Re: How to make Ada a dominant language) Hambut 2001-07-31 6:16 ` How to make Ada a dominant language Gary Lisyansky 6 siblings, 1 reply; 875+ messages in thread From: file13 @ 2001-07-30 17:51 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:51 ` file13 @ 2001-07-31 14:51 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-07-31 14:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Attributes of a development which require Ada (Was Re: How to make Ada a dominant language) 2001-07-30 15:02 ` Russ Paielli ` (4 preceding siblings ...) 2001-07-30 17:51 ` file13 @ 2001-07-30 22:35 ` Hambut 2001-07-31 6:16 ` How to make Ada a dominant language Gary Lisyansky 6 siblings, 0 replies; 875+ messages in thread From: Hambut @ 2001-07-30 22:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:02 ` Russ Paielli ` (5 preceding siblings ...) 2001-07-30 22:35 ` Attributes of a development which require Ada (Was Re: How to make Ada a dominant language) Hambut @ 2001-07-31 6:16 ` Gary Lisyansky 6 siblings, 0 replies; 875+ messages in thread From: Gary Lisyansky @ 2001-07-31 6:16 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:52 ` Gary Lisyansky 2001-07-30 13:38 ` Russ Paielli @ 2001-07-31 9:32 ` Philip Anderson 2001-07-31 10:16 ` Lutz Donnerhacke 2001-08-02 20:35 ` Barry Kelly 2001-08-16 5:19 ` David Thompson 3 siblings, 1 reply; 875+ messages in thread From: Philip Anderson @ 2001-07-31 9:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 9:32 ` Philip Anderson @ 2001-07-31 10:16 ` Lutz Donnerhacke 0 siblings, 0 replies; 875+ messages in thread From: Lutz Donnerhacke @ 2001-07-31 10:16 UTC (permalink / raw) * 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; ? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:52 ` Gary Lisyansky 2001-07-30 13:38 ` Russ Paielli 2001-07-31 9:32 ` Philip Anderson @ 2001-08-02 20:35 ` Barry Kelly 2001-08-03 0:07 ` Keith Thompson 2001-08-03 6:35 ` Gary Lisyansky 2001-08-16 5:19 ` David Thompson 3 siblings, 2 replies; 875+ messages in thread From: Barry Kelly @ 2001-08-02 20:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 20:35 ` Barry Kelly @ 2001-08-03 0:07 ` Keith Thompson 2001-08-03 6:35 ` Gary Lisyansky 1 sibling, 0 replies; 875+ messages in thread From: Keith Thompson @ 2001-08-03 0:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-02 20:35 ` Barry Kelly 2001-08-03 0:07 ` Keith Thompson @ 2001-08-03 6:35 ` Gary Lisyansky 1 sibling, 0 replies; 875+ messages in thread From: Gary Lisyansky @ 2001-08-03 6:35 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:52 ` Gary Lisyansky ` (2 preceding siblings ...) 2001-08-02 20:35 ` Barry Kelly @ 2001-08-16 5:19 ` David Thompson 3 siblings, 0 replies; 875+ messages in thread From: David Thompson @ 2001-08-16 5:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:41 ` Russ Paielli 2001-07-30 12:52 ` Preben Randhol 2001-07-30 12:52 ` Gary Lisyansky @ 2001-07-30 18:22 ` Stefan Nobis 2001-07-31 0:53 ` Adrian Hoe 2001-07-31 8:29 ` Florian Weimer 4 siblings, 0 replies; 875+ messages in thread From: Stefan Nobis @ 2001-07-30 18:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:41 ` Russ Paielli ` (2 preceding siblings ...) 2001-07-30 18:22 ` Stefan Nobis @ 2001-07-31 0:53 ` Adrian Hoe 2001-07-31 3:24 ` Russ Paielli 2001-07-31 8:29 ` Florian Weimer 4 siblings, 1 reply; 875+ messages in thread From: Adrian Hoe @ 2001-07-31 0:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 0:53 ` Adrian Hoe @ 2001-07-31 3:24 ` Russ Paielli 2001-07-31 6:47 ` Martin Dowie ` (3 more replies) 0 siblings, 4 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-31 3:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:24 ` Russ Paielli @ 2001-07-31 6:47 ` Martin Dowie 2001-07-31 7:10 ` Russ Paielli 2001-07-31 15:32 ` Ted Dennison 2001-07-31 11:16 ` David Gillon ` (2 subsequent siblings) 3 siblings, 2 replies; 875+ messages in thread From: Martin Dowie @ 2001-07-31 6:47 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 6:47 ` Martin Dowie @ 2001-07-31 7:10 ` Russ Paielli 2001-07-31 7:22 ` Gary Lisyansky ` (2 more replies) 2001-07-31 15:32 ` Ted Dennison 1 sibling, 3 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-31 7:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 7:10 ` Russ Paielli @ 2001-07-31 7:22 ` Gary Lisyansky 2001-07-31 7:38 ` Keith Thompson 2001-07-31 8:20 ` Martin Dowie 2 siblings, 0 replies; 875+ messages in thread From: Gary Lisyansky @ 2001-07-31 7:22 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 7:10 ` Russ Paielli 2001-07-31 7:22 ` Gary Lisyansky @ 2001-07-31 7:38 ` Keith Thompson 2001-07-31 8:20 ` Martin Dowie 2 siblings, 0 replies; 875+ messages in thread From: Keith Thompson @ 2001-07-31 7:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 7:10 ` Russ Paielli 2001-07-31 7:22 ` Gary Lisyansky 2001-07-31 7:38 ` Keith Thompson @ 2001-07-31 8:20 ` Martin Dowie 2 siblings, 0 replies; 875+ messages in thread From: Martin Dowie @ 2001-07-31 8:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 6:47 ` Martin Dowie 2001-07-31 7:10 ` Russ Paielli @ 2001-07-31 15:32 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-07-31 15:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:24 ` Russ Paielli 2001-07-31 6:47 ` Martin Dowie @ 2001-07-31 11:16 ` David Gillon 2001-08-01 1:25 ` Adrian Hoe 2001-08-01 10:08 ` AG 3 siblings, 0 replies; 875+ messages in thread From: David Gillon @ 2001-07-31 11:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:24 ` Russ Paielli 2001-07-31 6:47 ` Martin Dowie 2001-07-31 11:16 ` David Gillon @ 2001-08-01 1:25 ` Adrian Hoe 2001-08-01 4:25 ` Russ 2001-08-01 10:08 ` AG 3 siblings, 1 reply; 875+ messages in thread From: Adrian Hoe @ 2001-08-01 1:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 1:25 ` Adrian Hoe @ 2001-08-01 4:25 ` Russ 2001-08-01 8:22 ` MALAISE Pascal ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Russ @ 2001-08-01 4:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 4:25 ` Russ @ 2001-08-01 8:22 ` MALAISE Pascal 2001-08-01 9:34 ` Preben Randhol 2001-08-01 13:48 ` Stefan Nobis 2 siblings, 0 replies; 875+ messages in thread From: MALAISE Pascal @ 2001-08-01 8:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 4:25 ` Russ 2001-08-01 8:22 ` MALAISE Pascal @ 2001-08-01 9:34 ` Preben Randhol 2001-08-01 10:32 ` AG 2001-08-01 15:52 ` Russ 2001-08-01 13:48 ` Stefan Nobis 2 siblings, 2 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-01 9:34 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 9:34 ` Preben Randhol @ 2001-08-01 10:32 ` AG 2001-08-01 15:55 ` Russ 2001-08-01 15:52 ` Russ 1 sibling, 1 reply; 875+ messages in thread From: AG @ 2001-08-01 10:32 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 10:32 ` AG @ 2001-08-01 15:55 ` Russ 2001-08-01 16:50 ` chris.danx 0 siblings, 1 reply; 875+ messages in thread From: Russ @ 2001-08-01 15:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 15:55 ` Russ @ 2001-08-01 16:50 ` chris.danx 0 siblings, 0 replies; 875+ messages in thread From: chris.danx @ 2001-08-01 16:50 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 9:34 ` Preben Randhol 2001-08-01 10:32 ` AG @ 2001-08-01 15:52 ` Russ 1 sibling, 0 replies; 875+ messages in thread From: Russ @ 2001-08-01 15:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 4:25 ` Russ 2001-08-01 8:22 ` MALAISE Pascal 2001-08-01 9:34 ` Preben Randhol @ 2001-08-01 13:48 ` Stefan Nobis 2001-08-02 8:32 ` Pascal Obry 2 siblings, 1 reply; 875+ messages in thread From: Stefan Nobis @ 2001-08-01 13:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 13:48 ` Stefan Nobis @ 2001-08-02 8:32 ` Pascal Obry 0 siblings, 0 replies; 875+ messages in thread From: Pascal Obry @ 2001-08-02 8:32 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 3:24 ` Russ Paielli ` (2 preceding siblings ...) 2001-08-01 1:25 ` Adrian Hoe @ 2001-08-01 10:08 ` AG 3 siblings, 0 replies; 875+ messages in thread From: AG @ 2001-08-01 10:08 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:41 ` Russ Paielli ` (3 preceding siblings ...) 2001-07-31 0:53 ` Adrian Hoe @ 2001-07-31 8:29 ` Florian Weimer 2001-07-31 20:34 ` Keith Thompson 4 siblings, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-07-31 8:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 8:29 ` Florian Weimer @ 2001-07-31 20:34 ` Keith Thompson 2001-07-31 21:29 ` The concept of := (was How to make Ada a dominant language) Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Keith Thompson @ 2001-07-31 20:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: The concept of := (was How to make Ada a dominant language) 2001-07-31 20:34 ` Keith Thompson @ 2001-07-31 21:29 ` Warren W. Gay VE3WWG 2001-08-01 2:29 ` Keith Thompson 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj 0 siblings, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 21:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: The concept of := (was How to make Ada a dominant language) 2001-07-31 21:29 ` The concept of := (was How to make Ada a dominant language) Warren W. Gay VE3WWG @ 2001-08-01 2:29 ` Keith Thompson 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj 1 sibling, 0 replies; 875+ messages in thread From: Keith Thompson @ 2001-08-01 2:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* How Ada could have prevented the Red Code distributed denial of service attack. 2001-07-31 21:29 ` The concept of := (was How to make Ada a dominant language) Warren W. Gay VE3WWG 2001-08-01 2:29 ` Keith Thompson @ 2001-08-01 3:27 ` raj 2001-08-01 4:58 ` Martin Ambuhl ` (5 more replies) 1 sibling, 6 replies; 875+ messages in thread From: raj @ 2001-08-01 3:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj @ 2001-08-01 4:58 ` Martin Ambuhl 2001-08-01 5:01 ` Daniel Fischer ` (4 subsequent siblings) 5 siblings, 0 replies; 875+ messages in thread From: Martin Ambuhl @ 2001-08-01 4:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj 2001-08-01 4:58 ` Martin Ambuhl @ 2001-08-01 5:01 ` Daniel Fischer 2001-08-01 8:24 ` raj 2001-08-01 18:44 ` Lawrence Foard 2001-08-01 8:56 ` Richard Bos ` (3 subsequent siblings) 5 siblings, 2 replies; 875+ messages in thread From: Daniel Fischer @ 2001-08-01 5:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 5:01 ` Daniel Fischer @ 2001-08-01 8:24 ` raj 2001-08-01 12:55 ` Bart v Ingen Schenau 2001-08-01 18:44 ` Lawrence Foard 1 sibling, 1 reply; 875+ messages in thread From: raj @ 2001-08-01 8:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 8:24 ` raj @ 2001-08-01 12:55 ` Bart v Ingen Schenau 0 siblings, 0 replies; 875+ messages in thread From: Bart v Ingen Schenau @ 2001-08-01 12:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 5:01 ` Daniel Fischer 2001-08-01 8:24 ` raj @ 2001-08-01 18:44 ` Lawrence Foard 2001-08-01 19:58 ` Matthias Blume ` (2 more replies) 1 sibling, 3 replies; 875+ messages in thread From: Lawrence Foard @ 2001-08-01 18:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:44 ` Lawrence Foard @ 2001-08-01 19:58 ` Matthias Blume 2001-08-01 20:46 ` Kaz Kylheku 2001-08-02 8:54 ` Richard Bos 2 siblings, 0 replies; 875+ messages in thread From: Matthias Blume @ 2001-08-01 19:58 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:44 ` Lawrence Foard 2001-08-01 19:58 ` Matthias Blume @ 2001-08-01 20:46 ` Kaz Kylheku 2001-08-01 21:21 ` Marin David Condic 2001-08-02 8:54 ` Richard Bos 2 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-01 20:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 20:46 ` Kaz Kylheku @ 2001-08-01 21:21 ` Marin David Condic 2001-08-02 13:44 ` CBFalconer 2001-08-03 23:43 ` Tom Plunket 0 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-01 21:21 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 21:21 ` Marin David Condic @ 2001-08-02 13:44 ` CBFalconer 2001-08-03 23:43 ` Tom Plunket 1 sibling, 0 replies; 875+ messages in thread From: CBFalconer @ 2001-08-02 13:44 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 21:21 ` Marin David Condic 2001-08-02 13:44 ` CBFalconer @ 2001-08-03 23:43 ` Tom Plunket 2001-08-06 7:11 ` Dave Adlam 1 sibling, 1 reply; 875+ messages in thread From: Tom Plunket @ 2001-08-03 23:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 23:43 ` Tom Plunket @ 2001-08-06 7:11 ` Dave Adlam 0 siblings, 0 replies; 875+ messages in thread From: Dave Adlam @ 2001-08-06 7:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:44 ` Lawrence Foard 2001-08-01 19:58 ` Matthias Blume 2001-08-01 20:46 ` Kaz Kylheku @ 2001-08-02 8:54 ` Richard Bos 2001-08-03 3:20 ` Zoltan Somogyi 2 siblings, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-02 8:54 UTC (permalink / raw) 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"? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 8:54 ` Richard Bos @ 2001-08-03 3:20 ` Zoltan Somogyi 0 siblings, 0 replies; 875+ messages in thread From: Zoltan Somogyi @ 2001-08-03 3:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj 2001-08-01 4:58 ` Martin Ambuhl 2001-08-01 5:01 ` Daniel Fischer @ 2001-08-01 8:56 ` Richard Bos 2001-08-01 13:09 ` Mike Smith ` (2 subsequent siblings) 5 siblings, 0 replies; 875+ messages in thread From: Richard Bos @ 2001-08-01 8:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj ` (2 preceding siblings ...) 2001-08-01 8:56 ` Richard Bos @ 2001-08-01 13:09 ` Mike Smith 2001-08-01 15:32 ` Preben Randhol ` (2 more replies) 2001-08-07 14:34 ` Attila Feher 2001-08-12 7:41 ` How Ada " Will 5 siblings, 3 replies; 875+ messages in thread From: Mike Smith @ 2001-08-01 13:09 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 13:09 ` Mike Smith @ 2001-08-01 15:32 ` Preben Randhol 2001-08-01 16:24 ` Karl Heinz Buchegger 2001-08-01 20:36 ` Micah Cowan 2001-08-01 17:32 ` Scott Ingram 2001-08-01 17:49 ` Robert Dewar 2 siblings, 2 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-01 15:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 15:32 ` Preben Randhol @ 2001-08-01 16:24 ` Karl Heinz Buchegger 2001-08-07 23:55 ` Mark Lundquist 2001-08-01 20:36 ` Micah Cowan 1 sibling, 1 reply; 875+ messages in thread From: Karl Heinz Buchegger @ 2001-08-01 16:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 16:24 ` Karl Heinz Buchegger @ 2001-08-07 23:55 ` Mark Lundquist 0 siblings, 0 replies; 875+ messages in thread From: Mark Lundquist @ 2001-08-07 23:55 UTC (permalink / raw) "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... :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 15:32 ` Preben Randhol 2001-08-01 16:24 ` Karl Heinz Buchegger @ 2001-08-01 20:36 ` Micah Cowan 2001-08-01 22:05 ` Ed Falis ` (2 more replies) 1 sibling, 3 replies; 875+ messages in thread From: Micah Cowan @ 2001-08-01 20:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 20:36 ` Micah Cowan @ 2001-08-01 22:05 ` Ed Falis 2001-08-01 22:47 ` Micah Cowan 2001-08-02 13:44 ` CBFalconer 2001-08-01 22:56 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl 2001-08-02 7:54 ` Preben Randhol 2 siblings, 2 replies; 875+ messages in thread From: Ed Falis @ 2001-08-01 22:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:05 ` Ed Falis @ 2001-08-01 22:47 ` Micah Cowan 2001-08-02 3:37 ` Ed Falis 2001-08-02 13:44 ` CBFalconer 1 sibling, 1 reply; 875+ messages in thread From: Micah Cowan @ 2001-08-01 22:47 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:47 ` Micah Cowan @ 2001-08-02 3:37 ` Ed Falis 0 siblings, 0 replies; 875+ messages in thread From: Ed Falis @ 2001-08-02 3:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:05 ` Ed Falis 2001-08-01 22:47 ` Micah Cowan @ 2001-08-02 13:44 ` CBFalconer 2001-08-07 20:57 ` Albert van der Horst 1 sibling, 1 reply; 875+ messages in thread From: CBFalconer @ 2001-08-02 13:44 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 13:44 ` CBFalconer @ 2001-08-07 20:57 ` Albert van der Horst 2001-08-09 1:25 ` How Ada could have prevented the Red Code distributed denial of Larry Kilgallen 0 siblings, 1 reply; 875+ messages in thread From: Albert van der Horst @ 2001-08-07 20:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-07 20:57 ` Albert van der Horst @ 2001-08-09 1:25 ` Larry Kilgallen 0 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-09 1:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 20:36 ` Micah Cowan 2001-08-01 22:05 ` Ed Falis @ 2001-08-01 22:56 ` Markus Mottl 2001-08-01 23:13 ` Richard Heathfield 2001-08-02 3:11 ` Bruce G. Stewart 2001-08-02 7:54 ` Preben Randhol 2 siblings, 2 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-01 22:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:56 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl @ 2001-08-01 23:13 ` Richard Heathfield 2001-08-01 23:18 ` Kaz Kylheku ` (6 more replies) 2001-08-02 3:11 ` Bruce G. Stewart 1 sibling, 7 replies; 875+ messages in thread From: Richard Heathfield @ 2001-08-01 23:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:13 ` Richard Heathfield @ 2001-08-01 23:18 ` Kaz Kylheku 2001-08-02 4:10 ` gregm 2001-08-01 23:24 ` Markus Mottl ` (5 subsequent siblings) 6 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-01 23:18 UTC (permalink / raw) 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. :) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:18 ` Kaz Kylheku @ 2001-08-02 4:10 ` gregm 0 siblings, 0 replies; 875+ messages in thread From: gregm @ 2001-08-02 4:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:13 ` Richard Heathfield 2001-08-01 23:18 ` Kaz Kylheku @ 2001-08-01 23:24 ` Markus Mottl 2001-08-02 0:05 ` Aaron Denney ` (2 more replies) 2001-08-02 0:20 ` Darren New ` (4 subsequent siblings) 6 siblings, 3 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-01 23:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:24 ` Markus Mottl @ 2001-08-02 0:05 ` Aaron Denney 2001-08-02 9:13 ` Markus Mottl 2001-08-02 13:44 ` CBFalconer 2001-08-02 0:32 ` those who know me have no need of my name 2001-08-02 7:38 ` Richard Heathfield 2 siblings, 2 replies; 875+ messages in thread From: Aaron Denney @ 2001-08-02 0:05 UTC (permalink / raw) 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 -><- ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 0:05 ` Aaron Denney @ 2001-08-02 9:13 ` Markus Mottl 2001-08-02 13:44 ` CBFalconer 1 sibling, 0 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-02 9:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 0:05 ` Aaron Denney 2001-08-02 9:13 ` Markus Mottl @ 2001-08-02 13:44 ` CBFalconer 1 sibling, 0 replies; 875+ messages in thread From: CBFalconer @ 2001-08-02 13:44 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:24 ` Markus Mottl 2001-08-02 0:05 ` Aaron Denney @ 2001-08-02 0:32 ` those who know me have no need of my name 2001-08-02 7:38 ` Richard Heathfield 2 siblings, 0 replies; 875+ messages in thread From: those who know me have no need of my name @ 2001-08-02 0:32 UTC (permalink / raw) <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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:24 ` Markus Mottl 2001-08-02 0:05 ` Aaron Denney 2001-08-02 0:32 ` those who know me have no need of my name @ 2001-08-02 7:38 ` Richard Heathfield 2 siblings, 0 replies; 875+ messages in thread From: Richard Heathfield @ 2001-08-02 7:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:13 ` Richard Heathfield 2001-08-01 23:18 ` Kaz Kylheku 2001-08-01 23:24 ` Markus Mottl @ 2001-08-02 0:20 ` Darren New 2001-08-02 1:22 ` Michael Rubenstein ` (3 subsequent siblings) 6 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-02 0:20 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:13 ` Richard Heathfield ` (2 preceding siblings ...) 2001-08-02 0:20 ` Darren New @ 2001-08-02 1:22 ` Michael Rubenstein 2001-08-02 5:49 ` Fergus Henderson ` (2 subsequent siblings) 6 siblings, 0 replies; 875+ messages in thread From: Michael Rubenstein @ 2001-08-02 1:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:13 ` Richard Heathfield ` (3 preceding siblings ...) 2001-08-02 1:22 ` Michael Rubenstein @ 2001-08-02 5:49 ` Fergus Henderson 2001-08-02 6:44 ` Chris Kuan 2001-08-02 8:28 ` Zoltan Somogyi 2001-08-02 19:05 ` Wes Groleau 6 siblings, 1 reply; 875+ messages in thread From: Fergus Henderson @ 2001-08-02 5:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 5:49 ` Fergus Henderson @ 2001-08-02 6:44 ` Chris Kuan 2001-08-03 1:08 ` Chris Kuan 0 siblings, 1 reply; 875+ messages in thread From: Chris Kuan @ 2001-08-02 6:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 6:44 ` Chris Kuan @ 2001-08-03 1:08 ` Chris Kuan 0 siblings, 0 replies; 875+ messages in thread From: Chris Kuan @ 2001-08-03 1:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:13 ` Richard Heathfield ` (4 preceding siblings ...) 2001-08-02 5:49 ` Fergus Henderson @ 2001-08-02 8:28 ` Zoltan Somogyi 2001-08-02 19:05 ` Wes Groleau 6 siblings, 0 replies; 875+ messages in thread From: Zoltan Somogyi @ 2001-08-02 8:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:13 ` Richard Heathfield ` (5 preceding siblings ...) 2001-08-02 8:28 ` Zoltan Somogyi @ 2001-08-02 19:05 ` Wes Groleau 6 siblings, 0 replies; 875+ messages in thread From: Wes Groleau @ 2001-08-02 19:05 UTC (permalink / raw) > > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:56 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl 2001-08-01 23:13 ` Richard Heathfield @ 2001-08-02 3:11 ` Bruce G. Stewart 2001-08-02 3:21 ` Kaz Kylheku 2001-08-02 9:19 ` Markus Mottl 1 sibling, 2 replies; 875+ messages in thread From: Bruce G. Stewart @ 2001-08-02 3:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 3:11 ` Bruce G. Stewart @ 2001-08-02 3:21 ` Kaz Kylheku 2001-08-02 3:24 ` David Starner 2001-08-02 9:19 ` Markus Mottl 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-02 3:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 3:21 ` Kaz Kylheku @ 2001-08-02 3:24 ` David Starner 2001-08-02 6:53 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-02 3:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 3:24 ` David Starner @ 2001-08-02 6:53 ` Kaz Kylheku 0 siblings, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-02 6:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 3:11 ` Bruce G. Stewart 2001-08-02 3:21 ` Kaz Kylheku @ 2001-08-02 9:19 ` Markus Mottl 1 sibling, 0 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-02 9:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 20:36 ` Micah Cowan 2001-08-01 22:05 ` Ed Falis 2001-08-01 22:56 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl @ 2001-08-02 7:54 ` Preben Randhol 2 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-02 7:54 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 13:09 ` Mike Smith 2001-08-01 15:32 ` Preben Randhol @ 2001-08-01 17:32 ` Scott Ingram 2001-08-02 11:56 ` Beelsebob 2001-08-01 17:49 ` Robert Dewar 2 siblings, 1 reply; 875+ messages in thread From: Scott Ingram @ 2001-08-01 17:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 17:32 ` Scott Ingram @ 2001-08-02 11:56 ` Beelsebob 2001-08-02 12:15 ` Leif Roar Moldskred ` (4 more replies) 0 siblings, 5 replies; 875+ messages in thread From: Beelsebob @ 2001-08-02 11:56 UTC (permalink / raw) [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..... ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 11:56 ` Beelsebob @ 2001-08-02 12:15 ` Leif Roar Moldskred 2001-08-02 13:06 ` Charles Krug ` (3 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Leif Roar Moldskred @ 2001-08-02 12:15 UTC (permalink / raw) [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." ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 11:56 ` Beelsebob 2001-08-02 12:15 ` Leif Roar Moldskred @ 2001-08-02 13:06 ` Charles Krug 2001-08-02 14:12 ` Marin David Condic ` (2 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Charles Krug @ 2001-08-02 13:06 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 11:56 ` Beelsebob 2001-08-02 12:15 ` Leif Roar Moldskred 2001-08-02 13:06 ` Charles Krug @ 2001-08-02 14:12 ` Marin David Condic 2001-08-02 16:51 ` Scott Ingram 2001-08-03 0:44 ` How Ada could have prevented the Red Code distributed denial of service attack Mike Silva 4 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-02 14:12 UTC (permalink / raw) 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..... ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 11:56 ` Beelsebob ` (2 preceding siblings ...) 2001-08-02 14:12 ` Marin David Condic @ 2001-08-02 16:51 ` Scott Ingram 2001-08-02 19:21 ` How Ada could have prevented the Red Code distributed denial of Larry Kilgallen 2001-08-03 0:44 ` How Ada could have prevented the Red Code distributed denial of service attack Mike Silva 4 siblings, 1 reply; 875+ messages in thread From: Scott Ingram @ 2001-08-02 16:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-02 16:51 ` Scott Ingram @ 2001-08-02 19:21 ` Larry Kilgallen 0 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 19:21 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 11:56 ` Beelsebob ` (3 preceding siblings ...) 2001-08-02 16:51 ` Scott Ingram @ 2001-08-03 0:44 ` Mike Silva 4 siblings, 0 replies; 875+ messages in thread From: Mike Silva @ 2001-08-03 0:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 13:09 ` Mike Smith 2001-08-01 15:32 ` Preben Randhol 2001-08-01 17:32 ` Scott Ingram @ 2001-08-01 17:49 ` Robert Dewar 2001-08-01 18:11 ` Ted Dennison ` (2 more replies) 2 siblings, 3 replies; 875+ messages in thread From: Robert Dewar @ 2001-08-01 17:49 UTC (permalink / raw) "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++. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 17:49 ` Robert Dewar @ 2001-08-01 18:11 ` Ted Dennison 2001-08-01 18:40 ` Chris Torek ` (2 more replies) 2001-08-01 22:42 ` Hartmann Schaffer 2001-08-04 18:36 ` David Lee Lambert 2 siblings, 3 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-01 18:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:11 ` Ted Dennison @ 2001-08-01 18:40 ` Chris Torek 2001-08-01 20:04 ` Marin David Condic ` (2 more replies) 2001-08-01 18:43 ` Ted Dennison 2001-08-01 19:08 ` tmoran 2 siblings, 3 replies; 875+ messages in thread From: Chris Torek @ 2001-08-01 18:40 UTC (permalink / raw) 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@. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:40 ` Chris Torek @ 2001-08-01 20:04 ` Marin David Condic 2001-08-01 21:27 ` Chris Torek 2001-08-01 23:15 ` Larry Kilgallen 2001-08-01 21:40 ` Florian Weimer [not found] ` <GHEt6A.BzD@approve.se> 2 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-01 20:04 UTC (permalink / raw) 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." :-) > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 20:04 ` Marin David Condic @ 2001-08-01 21:27 ` Chris Torek 2001-08-02 0:15 ` Larry Kilgallen 2001-08-02 14:26 ` Marin David Condic 2001-08-01 23:15 ` Larry Kilgallen 1 sibling, 2 replies; 875+ messages in thread From: Chris Torek @ 2001-08-01 21:27 UTC (permalink / raw) 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@. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 21:27 ` Chris Torek @ 2001-08-02 0:15 ` Larry Kilgallen 2001-12-27 12:16 ` Florian Weimer 2001-08-02 14:26 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 0:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 0:15 ` Larry Kilgallen @ 2001-12-27 12:16 ` Florian Weimer 0 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-12-27 12:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 21:27 ` Chris Torek 2001-08-02 0:15 ` Larry Kilgallen @ 2001-08-02 14:26 ` Marin David Condic 2001-08-02 19:29 ` CBFalconer 1 sibling, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-02 14:26 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 14:26 ` Marin David Condic @ 2001-08-02 19:29 ` CBFalconer 0 siblings, 0 replies; 875+ messages in thread From: CBFalconer @ 2001-08-02 19:29 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 20:04 ` Marin David Condic 2001-08-01 21:27 ` Chris Torek @ 2001-08-01 23:15 ` Larry Kilgallen 2001-08-02 8:25 ` Richard Bos 2001-08-02 15:08 ` Marin David Condic 1 sibling, 2 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-01 23:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:15 ` Larry Kilgallen @ 2001-08-02 8:25 ` Richard Bos 2001-08-02 12:01 ` Larry Kilgallen 2001-08-02 21:52 ` Chris Torek 2001-08-02 15:08 ` Marin David Condic 1 sibling, 2 replies; 875+ messages in thread From: Richard Bos @ 2001-08-02 8:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 8:25 ` Richard Bos @ 2001-08-02 12:01 ` Larry Kilgallen 2001-08-02 21:52 ` Chris Torek 1 sibling, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 12:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 8:25 ` Richard Bos 2001-08-02 12:01 ` Larry Kilgallen @ 2001-08-02 21:52 ` Chris Torek 2001-08-03 6:05 ` Dan Cross 1 sibling, 1 reply; 875+ messages in thread From: Chris Torek @ 2001-08-02 21:52 UTC (permalink / raw) 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@. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 21:52 ` Chris Torek @ 2001-08-03 6:05 ` Dan Cross 2001-08-03 6:17 ` Kaz Kylheku 2001-08-03 11:24 ` Richard Bos 0 siblings, 2 replies; 875+ messages in thread From: Dan Cross @ 2001-08-03 6:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 6:05 ` Dan Cross @ 2001-08-03 6:17 ` Kaz Kylheku 2001-08-03 14:36 ` Dan Cross 2001-08-03 11:24 ` Richard Bos 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-03 6:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 6:17 ` Kaz Kylheku @ 2001-08-03 14:36 ` Dan Cross 2001-08-03 17:55 ` Kaz Kylheku 2001-08-03 18:15 ` Ted Dennison 0 siblings, 2 replies; 875+ messages in thread From: Dan Cross @ 2001-08-03 14:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:36 ` Dan Cross @ 2001-08-03 17:55 ` Kaz Kylheku 2001-08-03 18:01 ` Ben Pfaff ` (3 more replies) 2001-08-03 18:15 ` Ted Dennison 1 sibling, 4 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-03 17:55 UTC (permalink / raw) 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. ;) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 17:55 ` Kaz Kylheku @ 2001-08-03 18:01 ` Ben Pfaff 2001-08-03 18:23 ` Marc A. Criley ` (2 subsequent siblings) 3 siblings, 0 replies; 875+ messages in thread From: Ben Pfaff @ 2001-08-03 18:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 17:55 ` Kaz Kylheku 2001-08-03 18:01 ` Ben Pfaff @ 2001-08-03 18:23 ` Marc A. Criley 2001-08-05 3:38 ` AG 2001-08-13 20:23 ` Stefan Skoglund 3 siblings, 0 replies; 875+ messages in thread From: Marc A. Criley @ 2001-08-03 18:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 17:55 ` Kaz Kylheku 2001-08-03 18:01 ` Ben Pfaff 2001-08-03 18:23 ` Marc A. Criley @ 2001-08-05 3:38 ` AG 2001-08-13 20:23 ` Stefan Skoglund 3 siblings, 0 replies; 875+ messages in thread From: AG @ 2001-08-05 3:38 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 17:55 ` Kaz Kylheku ` (2 preceding siblings ...) 2001-08-05 3:38 ` AG @ 2001-08-13 20:23 ` Stefan Skoglund 3 siblings, 0 replies; 875+ messages in thread From: Stefan Skoglund @ 2001-08-13 20:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:36 ` Dan Cross 2001-08-03 17:55 ` Kaz Kylheku @ 2001-08-03 18:15 ` Ted Dennison 2001-08-03 19:09 ` Dan Cross 2001-08-03 21:54 ` Tore Lund 1 sibling, 2 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-03 18:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 18:15 ` Ted Dennison @ 2001-08-03 19:09 ` Dan Cross 2001-08-03 20:26 ` Ted Dennison 2001-08-03 21:54 ` Tore Lund 1 sibling, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-03 19:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 19:09 ` Dan Cross @ 2001-08-03 20:26 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-03 20:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 18:15 ` Ted Dennison 2001-08-03 19:09 ` Dan Cross @ 2001-08-03 21:54 ` Tore Lund 2001-08-06 3:35 ` Keith Thompson 2001-08-06 9:30 ` kers 1 sibling, 2 replies; 875+ messages in thread From: Tore Lund @ 2001-08-03 21:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 21:54 ` Tore Lund @ 2001-08-06 3:35 ` Keith Thompson 2001-08-06 23:36 ` Warren W. Gay VE3WWG 2001-08-06 9:30 ` kers 1 sibling, 1 reply; 875+ messages in thread From: Keith Thompson @ 2001-08-06 3:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 3:35 ` Keith Thompson @ 2001-08-06 23:36 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-06 23:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 21:54 ` Tore Lund 2001-08-06 3:35 ` Keith Thompson @ 2001-08-06 9:30 ` kers 1 sibling, 0 replies; 875+ messages in thread From: kers @ 2001-08-06 9:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 6:05 ` Dan Cross 2001-08-03 6:17 ` Kaz Kylheku @ 2001-08-03 11:24 ` Richard Bos 2001-08-03 14:41 ` Dan Cross 1 sibling, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-03 11:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 11:24 ` Richard Bos @ 2001-08-03 14:41 ` Dan Cross 2001-08-06 13:51 ` Richard Bos 0 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-03 14:41 UTC (permalink / raw) 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'. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:41 ` Dan Cross @ 2001-08-06 13:51 ` Richard Bos 2001-08-06 16:07 ` Dan Cross 2001-08-07 15:12 ` Scott Ingram 0 siblings, 2 replies; 875+ messages in thread From: Richard Bos @ 2001-08-06 13:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 13:51 ` Richard Bos @ 2001-08-06 16:07 ` Dan Cross 2001-08-07 15:12 ` Scott Ingram 1 sibling, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-06 16:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 13:51 ` Richard Bos 2001-08-06 16:07 ` Dan Cross @ 2001-08-07 15:12 ` Scott Ingram 1 sibling, 0 replies; 875+ messages in thread From: Scott Ingram @ 2001-08-07 15:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:15 ` Larry Kilgallen 2001-08-02 8:25 ` Richard Bos @ 2001-08-02 15:08 ` Marin David Condic 2001-08-03 0:34 ` Mike Silva 1 sibling, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-02 15:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 15:08 ` Marin David Condic @ 2001-08-03 0:34 ` Mike Silva 0 siblings, 0 replies; 875+ messages in thread From: Mike Silva @ 2001-08-03 0:34 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:40 ` Chris Torek 2001-08-01 20:04 ` Marin David Condic @ 2001-08-01 21:40 ` Florian Weimer [not found] ` <GHEt6A.BzD@approve.se> 2 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-01 21:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <GHEt6A.BzD@approve.se>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHEt6A.BzD@approve.se> @ 2001-08-01 22:12 ` Ed Falis [not found] ` <GHFDJp.G7q@approve.se> 0 siblings, 1 reply; 875+ messages in thread From: Ed Falis @ 2001-08-01 22:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <GHFDJp.G7q@approve.se>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHFDJp.G7q@approve.se> @ 2001-08-02 7:41 ` Preben Randhol [not found] ` <GHGA3t.Izq@approve.se> 2001-08-02 19:25 ` Tor Rustad 2001-08-02 13:02 ` Ed Falis 1 sibling, 2 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-02 7:41 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <GHGA3t.Izq@approve.se>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGA3t.Izq@approve.se> @ 2001-08-02 17:30 ` David Gillon 2001-08-02 17:37 ` Marin David Condic ` (4 subsequent siblings) 5 siblings, 0 replies; 875+ messages in thread From: David Gillon @ 2001-08-02 17:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGA3t.Izq@approve.se> 2001-08-02 17:30 ` David Gillon @ 2001-08-02 17:37 ` Marin David Condic [not found] ` <GHGGJH.JpI@approve.se> 2001-08-02 21:56 ` Warren W. Gay VE3WWG 2001-08-02 17:38 ` Scott Ingram ` (3 subsequent siblings) 5 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-02 17:37 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <GHGGJH.JpI@approve.se>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGGJH.JpI@approve.se> @ 2001-08-02 20:11 ` Darren New 2001-08-02 20:37 ` Marin David Condic 2001-08-02 20:55 ` Dan Cross 2 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-02 20:11 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGGJH.JpI@approve.se> 2001-08-02 20:11 ` Darren New @ 2001-08-02 20:37 ` Marin David Condic 2001-08-03 10:15 ` Reivilo Snuved 2001-08-02 20:55 ` Dan Cross 2 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-02 20:37 UTC (permalink / raw) 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? > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 20:37 ` Marin David Condic @ 2001-08-03 10:15 ` Reivilo Snuved 2001-08-03 14:15 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Reivilo Snuved @ 2001-08-03 10:15 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 10:15 ` Reivilo Snuved @ 2001-08-03 14:15 ` Marin David Condic 2001-08-03 14:55 ` Reivilo Snuved 2001-08-03 14:44 ` Dan Cross 2001-08-03 17:00 ` Mike Silva 2 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-03 14:15 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:15 ` Marin David Condic @ 2001-08-03 14:55 ` Reivilo Snuved 0 siblings, 0 replies; 875+ messages in thread From: Reivilo Snuved @ 2001-08-03 14:55 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 10:15 ` Reivilo Snuved 2001-08-03 14:15 ` Marin David Condic @ 2001-08-03 14:44 ` Dan Cross 2001-08-03 15:02 ` Reivilo Snuved 2001-08-03 15:38 ` Marin David Condic 2001-08-03 17:00 ` Mike Silva 2 siblings, 2 replies; 875+ messages in thread From: Dan Cross @ 2001-08-03 14:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:44 ` Dan Cross @ 2001-08-03 15:02 ` Reivilo Snuved 2001-08-03 15:38 ` Marin David Condic 1 sibling, 0 replies; 875+ messages in thread From: Reivilo Snuved @ 2001-08-03 15:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:44 ` Dan Cross 2001-08-03 15:02 ` Reivilo Snuved @ 2001-08-03 15:38 ` Marin David Condic 1 sibling, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-03 15:38 UTC (permalink / raw) 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! > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 10:15 ` Reivilo Snuved 2001-08-03 14:15 ` Marin David Condic 2001-08-03 14:44 ` Dan Cross @ 2001-08-03 17:00 ` Mike Silva 2001-08-03 17:21 ` Mike Williams 2 siblings, 1 reply; 875+ messages in thread From: Mike Silva @ 2001-08-03 17:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 17:00 ` Mike Silva @ 2001-08-03 17:21 ` Mike Williams 2001-08-05 21:39 ` Mike Silva 0 siblings, 1 reply; 875+ messages in thread From: Mike Williams @ 2001-08-03 17:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 17:21 ` Mike Williams @ 2001-08-05 21:39 ` Mike Silva 2001-08-06 14:32 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Mike Silva @ 2001-08-05 21:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-05 21:39 ` Mike Silva @ 2001-08-06 14:32 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-06 14:32 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGGJH.JpI@approve.se> 2001-08-02 20:11 ` Darren New 2001-08-02 20:37 ` Marin David Condic @ 2001-08-02 20:55 ` Dan Cross 2 siblings, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-02 20:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 17:37 ` Marin David Condic [not found] ` <GHGGJH.JpI@approve.se> @ 2001-08-02 21:56 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-02 21:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGA3t.Izq@approve.se> 2001-08-02 17:30 ` David Gillon 2001-08-02 17:37 ` Marin David Condic @ 2001-08-02 17:38 ` Scott Ingram 2001-08-02 17:54 ` Ruslan Abdikeev 2001-08-02 18:01 ` Dan Cross ` (2 subsequent siblings) 5 siblings, 1 reply; 875+ messages in thread From: Scott Ingram @ 2001-08-02 17:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 17:38 ` Scott Ingram @ 2001-08-02 17:54 ` Ruslan Abdikeev 0 siblings, 0 replies; 875+ messages in thread From: Ruslan Abdikeev @ 2001-08-02 17:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGA3t.Izq@approve.se> ` (2 preceding siblings ...) 2001-08-02 17:38 ` Scott Ingram @ 2001-08-02 18:01 ` Dan Cross 2001-08-02 19:24 ` Larry Kilgallen 2001-08-02 19:29 ` CBFalconer 5 siblings, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-02 18:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGA3t.Izq@approve.se> ` (3 preceding siblings ...) 2001-08-02 18:01 ` Dan Cross @ 2001-08-02 19:24 ` Larry Kilgallen 2001-08-02 18:44 ` Daniel Fischer 2001-08-02 19:05 ` Darren New 2001-08-02 19:29 ` CBFalconer 5 siblings, 2 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-02 19:24 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 19:24 ` Larry Kilgallen @ 2001-08-02 18:44 ` Daniel Fischer 2001-08-03 7:53 ` Christian Bau 2001-08-02 19:05 ` Darren New 1 sibling, 1 reply; 875+ messages in thread From: Daniel Fischer @ 2001-08-02 18:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 18:44 ` Daniel Fischer @ 2001-08-03 7:53 ` Christian Bau 2001-08-03 8:02 ` Daniel Fischer 2001-08-03 14:41 ` Marin David Condic 0 siblings, 2 replies; 875+ messages in thread From: Christian Bau @ 2001-08-03 7:53 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 7:53 ` Christian Bau @ 2001-08-03 8:02 ` Daniel Fischer 2001-08-03 9:27 ` Christian Bau 2001-08-03 14:41 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Daniel Fischer @ 2001-08-03 8:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 8:02 ` Daniel Fischer @ 2001-08-03 9:27 ` Christian Bau 2001-08-03 10:01 ` Daniel Fischer 2001-08-03 14:46 ` Marin David Condic 0 siblings, 2 replies; 875+ messages in thread From: Christian Bau @ 2001-08-03 9:27 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 9:27 ` Christian Bau @ 2001-08-03 10:01 ` Daniel Fischer 2001-08-03 14:46 ` Marin David Condic 1 sibling, 0 replies; 875+ messages in thread From: Daniel Fischer @ 2001-08-03 10:01 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 9:27 ` Christian Bau 2001-08-03 10:01 ` Daniel Fischer @ 2001-08-03 14:46 ` Marin David Condic 1 sibling, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-03 14:46 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 7:53 ` Christian Bau 2001-08-03 8:02 ` Daniel Fischer @ 2001-08-03 14:41 ` Marin David Condic 2001-08-04 14:11 ` Tor Rustad 1 sibling, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-03 14:41 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:41 ` Marin David Condic @ 2001-08-04 14:11 ` Tor Rustad 2001-08-06 14:42 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Tor Rustad @ 2001-08-04 14:11 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 14:11 ` Tor Rustad @ 2001-08-06 14:42 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-06 14:42 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 19:24 ` Larry Kilgallen 2001-08-02 18:44 ` Daniel Fischer @ 2001-08-02 19:05 ` Darren New 1 sibling, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-02 19:05 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHGA3t.Izq@approve.se> ` (4 preceding siblings ...) 2001-08-02 19:24 ` Larry Kilgallen @ 2001-08-02 19:29 ` CBFalconer 5 siblings, 0 replies; 875+ messages in thread From: CBFalconer @ 2001-08-02 19:29 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 7:41 ` Preben Randhol [not found] ` <GHGA3t.Izq@approve.se> @ 2001-08-02 19:25 ` Tor Rustad 2001-08-03 3:11 ` Mike Silva 1 sibling, 1 reply; 875+ messages in thread From: Tor Rustad @ 2001-08-02 19:25 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 19:25 ` Tor Rustad @ 2001-08-03 3:11 ` Mike Silva 2001-08-04 0:26 ` Tor Rustad 0 siblings, 1 reply; 875+ messages in thread From: Mike Silva @ 2001-08-03 3:11 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 3:11 ` Mike Silva @ 2001-08-04 0:26 ` Tor Rustad 2001-08-04 2:50 ` James Rogers ` (3 more replies) 0 siblings, 4 replies; 875+ messages in thread From: Tor Rustad @ 2001-08-04 0:26 UTC (permalink / raw) "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> ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 0:26 ` Tor Rustad @ 2001-08-04 2:50 ` James Rogers 2001-08-04 14:07 ` Tor Rustad 2001-08-05 22:15 ` How Ada could have prevented the Red Code distributed denial of service attack Mike Silva ` (2 subsequent siblings) 3 siblings, 1 reply; 875+ messages in thread From: James Rogers @ 2001-08-04 2:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 2:50 ` James Rogers @ 2001-08-04 14:07 ` Tor Rustad 2001-08-04 14:56 ` James Rogers ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Tor Rustad @ 2001-08-04 14:07 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 14:07 ` Tor Rustad @ 2001-08-04 14:56 ` James Rogers 2001-08-05 12:44 ` Tor Rustad 2001-08-06 0:22 ` Larry Kilgallen 2001-08-06 14:17 ` Ted Dennison 2 siblings, 1 reply; 875+ messages in thread From: James Rogers @ 2001-08-04 14:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 14:56 ` James Rogers @ 2001-08-05 12:44 ` Tor Rustad 0 siblings, 0 replies; 875+ messages in thread From: Tor Rustad @ 2001-08-05 12:44 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 14:07 ` Tor Rustad 2001-08-04 14:56 ` James Rogers @ 2001-08-06 0:22 ` Larry Kilgallen 2001-08-06 13:51 ` Richard Bos ` (2 more replies) 2001-08-06 14:17 ` Ted Dennison 2 siblings, 3 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-06 0:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 0:22 ` Larry Kilgallen @ 2001-08-06 13:51 ` Richard Bos 2001-08-06 16:23 ` Dan Cross 2001-08-06 14:13 ` Ted Dennison 2001-08-06 16:17 ` Larry Kilgallen 2 siblings, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-06 13:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 13:51 ` Richard Bos @ 2001-08-06 16:23 ` Dan Cross 0 siblings, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-06 16:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 0:22 ` Larry Kilgallen 2001-08-06 13:51 ` Richard Bos @ 2001-08-06 14:13 ` Ted Dennison 2001-08-06 16:17 ` Larry Kilgallen 2 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-06 14:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 0:22 ` Larry Kilgallen 2001-08-06 13:51 ` Richard Bos 2001-08-06 14:13 ` Ted Dennison @ 2001-08-06 16:17 ` Larry Kilgallen 2 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-06 16:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 14:07 ` Tor Rustad 2001-08-04 14:56 ` James Rogers 2001-08-06 0:22 ` Larry Kilgallen @ 2001-08-06 14:17 ` Ted Dennison 2001-08-06 14:03 ` Richard Bos ` (2 more replies) 2 siblings, 3 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-06 14:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 14:17 ` Ted Dennison @ 2001-08-06 14:03 ` Richard Bos 2001-08-06 15:02 ` Yoann Padioleau 2001-08-06 16:35 ` Aaron Denney 2001-08-07 19:43 ` David Lee Lambert 2 siblings, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-06 14:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 14:03 ` Richard Bos @ 2001-08-06 15:02 ` Yoann Padioleau 2001-08-06 15:17 ` Matthias Blume 2001-08-06 16:42 ` Aaron Denney 0 siblings, 2 replies; 875+ messages in thread From: Yoann Padioleau @ 2001-08-06 15:02 UTC (permalink / raw) [-- 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. ____** ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 15:02 ` Yoann Padioleau @ 2001-08-06 15:17 ` Matthias Blume 2001-08-06 16:42 ` Aaron Denney 1 sibling, 0 replies; 875+ messages in thread From: Matthias Blume @ 2001-08-06 15:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 15:02 ` Yoann Padioleau 2001-08-06 15:17 ` Matthias Blume @ 2001-08-06 16:42 ` Aaron Denney 1 sibling, 0 replies; 875+ messages in thread From: Aaron Denney @ 2001-08-06 16:42 UTC (permalink / raw) 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 -><- ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 14:17 ` Ted Dennison 2001-08-06 14:03 ` Richard Bos @ 2001-08-06 16:35 ` Aaron Denney 2001-08-07 19:43 ` David Lee Lambert 2 siblings, 0 replies; 875+ messages in thread From: Aaron Denney @ 2001-08-06 16:35 UTC (permalink / raw) 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 -><- ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 14:17 ` Ted Dennison 2001-08-06 14:03 ` Richard Bos 2001-08-06 16:35 ` Aaron Denney @ 2001-08-07 19:43 ` David Lee Lambert 2001-08-07 20:15 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2 siblings, 1 reply; 875+ messages in thread From: David Lee Lambert @ 2001-08-07 19:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-07 19:43 ` David Lee Lambert @ 2001-08-07 20:15 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-07 20:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 0:26 ` Tor Rustad 2001-08-04 2:50 ` James Rogers @ 2001-08-05 22:15 ` Mike Silva 2001-08-06 11:44 ` David Gillon 2001-08-06 14:59 ` Marin David Condic 3 siblings, 0 replies; 875+ messages in thread From: Mike Silva @ 2001-08-05 22:15 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 0:26 ` Tor Rustad 2001-08-04 2:50 ` James Rogers 2001-08-05 22:15 ` How Ada could have prevented the Red Code distributed denial of service attack Mike Silva @ 2001-08-06 11:44 ` David Gillon 2001-08-06 14:59 ` Marin David Condic 3 siblings, 0 replies; 875+ messages in thread From: David Gillon @ 2001-08-06 11:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 0:26 ` Tor Rustad ` (2 preceding siblings ...) 2001-08-06 11:44 ` David Gillon @ 2001-08-06 14:59 ` Marin David Condic 2001-08-06 18:12 ` CBFalconer 3 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-06 14:59 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 14:59 ` Marin David Condic @ 2001-08-06 18:12 ` CBFalconer 2001-08-06 19:35 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: CBFalconer @ 2001-08-06 18:12 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 18:12 ` CBFalconer @ 2001-08-06 19:35 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-06 19:35 UTC (permalink / raw) 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". > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <GHFDJp.G7q@approve.se> 2001-08-02 7:41 ` Preben Randhol @ 2001-08-02 13:02 ` Ed Falis 2001-08-02 15:24 ` Marin David Condic 2001-08-02 16:02 ` Reivilo Snuved 1 sibling, 2 replies; 875+ messages in thread From: Ed Falis @ 2001-08-02 13:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 13:02 ` Ed Falis @ 2001-08-02 15:24 ` Marin David Condic 2001-08-02 16:02 ` Reivilo Snuved 1 sibling, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-02 15:24 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 13:02 ` Ed Falis 2001-08-02 15:24 ` Marin David Condic @ 2001-08-02 16:02 ` Reivilo Snuved 1 sibling, 0 replies; 875+ messages in thread From: Reivilo Snuved @ 2001-08-02 16:02 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:11 ` Ted Dennison 2001-08-01 18:40 ` Chris Torek @ 2001-08-01 18:43 ` Ted Dennison 2001-08-01 21:07 ` Mike Smith 2001-08-01 19:08 ` tmoran 2 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-01 18:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:43 ` Ted Dennison @ 2001-08-01 21:07 ` Mike Smith 2001-08-01 22:12 ` Dale Stanbrough ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Mike Smith @ 2001-08-01 21:07 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 21:07 ` Mike Smith @ 2001-08-01 22:12 ` Dale Stanbrough 2001-08-01 22:40 ` Kaz Kylheku 2001-08-01 22:44 ` Dan Cross [not found] ` <dale-8EE262.08123502082001@mec2. <Xz%97.2632$B37.106689@news1.rdc1.bc.home.com> 2 siblings, 1 reply; 875+ messages in thread From: Dale Stanbrough @ 2001-08-01 22:12 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:12 ` Dale Stanbrough @ 2001-08-01 22:40 ` Kaz Kylheku 2001-08-01 23:00 ` Dale Stanbrough 2001-08-02 6:55 ` Ketil Z Malde 0 siblings, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-01 22:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:40 ` Kaz Kylheku @ 2001-08-01 23:00 ` Dale Stanbrough 2001-08-02 5:00 ` Warren W. Gay VE3WWG 2001-08-02 8:25 ` Richard Bos 2001-08-02 6:55 ` Ketil Z Malde 1 sibling, 2 replies; 875+ messages in thread From: Dale Stanbrough @ 2001-08-01 23:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:00 ` Dale Stanbrough @ 2001-08-02 5:00 ` Warren W. Gay VE3WWG 2001-08-02 15:53 ` Brian Rogoff 2001-08-02 8:25 ` Richard Bos 1 sibling, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-02 5:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 5:00 ` Warren W. Gay VE3WWG @ 2001-08-02 15:53 ` Brian Rogoff 0 siblings, 0 replies; 875+ messages in thread From: Brian Rogoff @ 2001-08-02 15:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:00 ` Dale Stanbrough 2001-08-02 5:00 ` Warren W. Gay VE3WWG @ 2001-08-02 8:25 ` Richard Bos 2001-08-02 10:09 ` Martin Dowie 2001-08-02 17:30 ` CBFalconer 1 sibling, 2 replies; 875+ messages in thread From: Richard Bos @ 2001-08-02 8:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 8:25 ` Richard Bos @ 2001-08-02 10:09 ` Martin Dowie 2001-08-03 7:26 ` Richard Bos 2001-08-02 17:30 ` CBFalconer 1 sibling, 1 reply; 875+ messages in thread From: Martin Dowie @ 2001-08-02 10:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 10:09 ` Martin Dowie @ 2001-08-03 7:26 ` Richard Bos 2001-08-03 12:06 ` Martin Dowie 0 siblings, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-03 7:26 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 7:26 ` Richard Bos @ 2001-08-03 12:06 ` Martin Dowie 0 siblings, 0 replies; 875+ messages in thread From: Martin Dowie @ 2001-08-03 12:06 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 8:25 ` Richard Bos 2001-08-02 10:09 ` Martin Dowie @ 2001-08-02 17:30 ` CBFalconer 2001-08-05 8:06 ` Marcin 'Qrczak' Kowalczyk 1 sibling, 1 reply; 875+ messages in thread From: CBFalconer @ 2001-08-02 17:30 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 17:30 ` CBFalconer @ 2001-08-05 8:06 ` Marcin 'Qrczak' Kowalczyk 0 siblings, 0 replies; 875+ messages in thread From: Marcin 'Qrczak' Kowalczyk @ 2001-08-05 8:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:40 ` Kaz Kylheku 2001-08-01 23:00 ` Dale Stanbrough @ 2001-08-02 6:55 ` Ketil Z Malde 1 sibling, 0 replies; 875+ messages in thread From: Ketil Z Malde @ 2001-08-02 6:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 21:07 ` Mike Smith 2001-08-01 22:12 ` Dale Stanbrough @ 2001-08-01 22:44 ` Dan Cross 2001-08-01 23:29 ` Aaron Denney 2001-08-02 2:19 ` Mike Smith [not found] ` <dale-8EE262.08123502082001@mec2. <Xz%97.2632$B37.106689@news1.rdc1.bc.home.com> 2 siblings, 2 replies; 875+ messages in thread From: Dan Cross @ 2001-08-01 22:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:44 ` Dan Cross @ 2001-08-01 23:29 ` Aaron Denney 2001-08-02 2:19 ` Mike Smith 1 sibling, 0 replies; 875+ messages in thread From: Aaron Denney @ 2001-08-01 23:29 UTC (permalink / raw) 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 -><- ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:44 ` Dan Cross 2001-08-01 23:29 ` Aaron Denney @ 2001-08-02 2:19 ` Mike Smith 2001-08-02 8:17 ` Bill Godfrey ` (3 more replies) 1 sibling, 4 replies; 875+ messages in thread From: Mike Smith @ 2001-08-02 2:19 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 2:19 ` Mike Smith @ 2001-08-02 8:17 ` Bill Godfrey 2001-08-02 10:14 ` Martin Dowie ` (2 subsequent siblings) 3 siblings, 0 replies; 875+ messages in thread From: Bill Godfrey @ 2001-08-02 8:17 UTC (permalink / raw) "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.) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 2:19 ` Mike Smith 2001-08-02 8:17 ` Bill Godfrey @ 2001-08-02 10:14 ` Martin Dowie 2001-08-02 19:23 ` Tor Rustad 2001-08-02 15:37 ` Marin David Condic 2001-08-02 15:50 ` Dan Cross 3 siblings, 1 reply; 875+ messages in thread From: Martin Dowie @ 2001-08-02 10:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 10:14 ` Martin Dowie @ 2001-08-02 19:23 ` Tor Rustad 2001-08-03 8:05 ` Martin Dowie 0 siblings, 1 reply; 875+ messages in thread From: Tor Rustad @ 2001-08-02 19:23 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 19:23 ` Tor Rustad @ 2001-08-03 8:05 ` Martin Dowie 0 siblings, 0 replies; 875+ messages in thread From: Martin Dowie @ 2001-08-03 8:05 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 2:19 ` Mike Smith 2001-08-02 8:17 ` Bill Godfrey 2001-08-02 10:14 ` Martin Dowie @ 2001-08-02 15:37 ` Marin David Condic 2001-08-02 17:25 ` David Gillon 2001-08-02 15:50 ` Dan Cross 3 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-02 15:37 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 15:37 ` Marin David Condic @ 2001-08-02 17:25 ` David Gillon 0 siblings, 0 replies; 875+ messages in thread From: David Gillon @ 2001-08-02 17:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 2:19 ` Mike Smith ` (2 preceding siblings ...) 2001-08-02 15:37 ` Marin David Condic @ 2001-08-02 15:50 ` Dan Cross 2001-08-03 6:26 ` Mike Williams 3 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-02 15:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 15:50 ` Dan Cross @ 2001-08-03 6:26 ` Mike Williams 2001-08-03 14:07 ` Richard Bos 2001-08-03 14:31 ` Dan Cross 0 siblings, 2 replies; 875+ messages in thread From: Mike Williams @ 2001-08-03 6:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 6:26 ` Mike Williams @ 2001-08-03 14:07 ` Richard Bos 2001-08-03 14:31 ` Dan Cross 1 sibling, 0 replies; 875+ messages in thread From: Richard Bos @ 2001-08-03 14:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 6:26 ` Mike Williams 2001-08-03 14:07 ` Richard Bos @ 2001-08-03 14:31 ` Dan Cross 1 sibling, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-03 14:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <dale-8EE262.08123502082001@mec2. <Xz%97.2632$B37.106689@news1.rdc1.bc.home.com>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <dale-8EE262.08123502082001@mec2. <Xz%97.2632$B37.106689@news1.rdc1.bc.home.com> @ 2001-08-01 22:58 ` Dan Cross 2001-08-02 8:25 ` Richard Bos 0 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-01 22:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:58 ` Dan Cross @ 2001-08-02 8:25 ` Richard Bos 2001-08-02 9:25 ` Markus Mottl 2001-08-02 16:10 ` Dan Cross 0 siblings, 2 replies; 875+ messages in thread From: Richard Bos @ 2001-08-02 8:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 8:25 ` Richard Bos @ 2001-08-02 9:25 ` Markus Mottl 2001-08-02 16:10 ` Dan Cross 1 sibling, 0 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-02 9:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 8:25 ` Richard Bos 2001-08-02 9:25 ` Markus Mottl @ 2001-08-02 16:10 ` Dan Cross 2001-08-02 16:20 ` Daniel Fischer ` (2 more replies) 1 sibling, 3 replies; 875+ messages in thread From: Dan Cross @ 2001-08-02 16:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 16:10 ` Dan Cross @ 2001-08-02 16:20 ` Daniel Fischer 2001-08-02 16:42 ` Dan Cross 2001-08-03 7:26 ` Richard Bos 2001-08-06 18:55 ` Bart.Vanhauwaert 2 siblings, 1 reply; 875+ messages in thread From: Daniel Fischer @ 2001-08-02 16:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 16:20 ` Daniel Fischer @ 2001-08-02 16:42 ` Dan Cross 2001-08-02 17:29 ` Marin David Condic 2001-08-02 22:58 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 875+ messages in thread From: Dan Cross @ 2001-08-02 16:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 16:42 ` Dan Cross @ 2001-08-02 17:29 ` Marin David Condic 2001-08-02 18:04 ` Daniel Fischer 2001-08-02 18:06 ` Dan Cross 2001-08-02 22:58 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-02 17:29 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 17:29 ` Marin David Condic @ 2001-08-02 18:04 ` Daniel Fischer 2001-08-02 18:06 ` Dan Cross 1 sibling, 0 replies; 875+ messages in thread From: Daniel Fischer @ 2001-08-02 18:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 17:29 ` Marin David Condic 2001-08-02 18:04 ` Daniel Fischer @ 2001-08-02 18:06 ` Dan Cross 1 sibling, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-02 18:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 16:42 ` Dan Cross 2001-08-02 17:29 ` Marin David Condic @ 2001-08-02 22:58 ` Warren W. Gay VE3WWG 2001-08-03 8:25 ` CBFalconer 2001-08-06 21:26 ` Bart.Vanhauwaert 1 sibling, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-02 22:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 22:58 ` Warren W. Gay VE3WWG @ 2001-08-03 8:25 ` CBFalconer 2001-08-06 21:26 ` Bart.Vanhauwaert 1 sibling, 0 replies; 875+ messages in thread From: CBFalconer @ 2001-08-03 8:25 UTC (permalink / raw) "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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 22:58 ` Warren W. Gay VE3WWG 2001-08-03 8:25 ` CBFalconer @ 2001-08-06 21:26 ` Bart.Vanhauwaert 2001-08-07 0:07 ` Warren W. Gay VE3WWG 2001-08-07 16:20 ` Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-06 21:26 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 21:26 ` Bart.Vanhauwaert @ 2001-08-07 0:07 ` Warren W. Gay VE3WWG 2001-08-07 0:15 ` Kaz Kylheku ` (2 more replies) 2001-08-07 16:20 ` Ted Dennison 1 sibling, 3 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-07 0:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:07 ` Warren W. Gay VE3WWG @ 2001-08-07 0:15 ` Kaz Kylheku 2001-08-07 3:04 ` Warren W. Gay VE3WWG 2001-08-07 11:53 ` Larry Kilgallen 2001-08-07 11:57 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 2001-08-13 20:54 ` Stefan Skoglund 2 siblings, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-07 0:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:15 ` Kaz Kylheku @ 2001-08-07 3:04 ` Warren W. Gay VE3WWG 2001-08-07 3:18 ` Francois Labreque 2001-08-07 5:14 ` Kaz Kylheku 2001-08-07 11:53 ` Larry Kilgallen 1 sibling, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-07 3:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:04 ` Warren W. Gay VE3WWG @ 2001-08-07 3:18 ` Francois Labreque 2001-08-07 4:10 ` Warren W. Gay VE3WWG 2001-08-07 5:14 ` Kaz Kylheku 1 sibling, 1 reply; 875+ messages in thread From: Francois Labreque @ 2001-08-07 3:18 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:18 ` Francois Labreque @ 2001-08-07 4:10 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-07 4:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:04 ` Warren W. Gay VE3WWG 2001-08-07 3:18 ` Francois Labreque @ 2001-08-07 5:14 ` Kaz Kylheku 2001-08-07 12:04 ` Larry Kilgallen 2001-08-07 17:16 ` Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-07 5:14 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 5:14 ` Kaz Kylheku @ 2001-08-07 12:04 ` Larry Kilgallen 2001-08-07 17:16 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-07 12:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 5:14 ` Kaz Kylheku 2001-08-07 12:04 ` Larry Kilgallen @ 2001-08-07 17:16 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-07 17:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:15 ` Kaz Kylheku 2001-08-07 3:04 ` Warren W. Gay VE3WWG @ 2001-08-07 11:53 ` Larry Kilgallen 2001-08-07 16:12 ` Kaz Kylheku 2001-08-07 17:28 ` Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-07 11:53 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 11:53 ` Larry Kilgallen @ 2001-08-07 16:12 ` Kaz Kylheku 2001-08-07 17:28 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-07 16:12 UTC (permalink / raw) 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! :) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 11:53 ` Larry Kilgallen 2001-08-07 16:12 ` Kaz Kylheku @ 2001-08-07 17:28 ` Ted Dennison 2001-08-07 17:56 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-07 17:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 17:28 ` Ted Dennison @ 2001-08-07 17:56 ` Marin David Condic 2001-08-07 18:36 ` David Starner 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-07 17:56 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 17:56 ` Marin David Condic @ 2001-08-07 18:36 ` David Starner 2001-08-07 21:14 ` Larry Kilgallen ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: David Starner @ 2001-08-07 18:36 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 18:36 ` David Starner @ 2001-08-07 21:14 ` Larry Kilgallen 2001-08-08 7:38 ` David Starner 2001-08-07 21:49 ` Marin David Condic 2001-08-08 10:40 ` A Directory package for Ada (was: How Ada could have prevented) Larry Kilgallen 2 siblings, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-08-07 21:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 21:14 ` Larry Kilgallen @ 2001-08-08 7:38 ` David Starner 0 siblings, 0 replies; 875+ messages in thread From: David Starner @ 2001-08-08 7:38 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 18:36 ` David Starner 2001-08-07 21:14 ` Larry Kilgallen @ 2001-08-07 21:49 ` Marin David Condic 2001-08-08 3:39 ` David Starner 2001-08-08 10:40 ` A Directory package for Ada (was: How Ada could have prevented) Larry Kilgallen 2 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-07 21:49 UTC (permalink / raw) 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.) > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 21:49 ` Marin David Condic @ 2001-08-08 3:39 ` David Starner 0 siblings, 0 replies; 875+ messages in thread From: David Starner @ 2001-08-08 3:39 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* A Directory package for Ada (was: How Ada could have prevented) 2001-08-07 18:36 ` David Starner 2001-08-07 21:14 ` Larry Kilgallen 2001-08-07 21:49 ` Marin David Condic @ 2001-08-08 10:40 ` Larry Kilgallen 2 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-08 10:40 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:07 ` Warren W. Gay VE3WWG 2001-08-07 0:15 ` Kaz Kylheku @ 2001-08-07 11:57 ` Bart.Vanhauwaert 2001-08-07 22:44 ` James Rogers 2001-08-08 2:59 ` Warren W. Gay VE3WWG 2001-08-13 20:54 ` Stefan Skoglund 2 siblings, 2 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-07 11:57 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 11:57 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert @ 2001-08-07 22:44 ` James Rogers 2001-08-08 4:04 ` Lao Xiao Hai 2001-08-08 21:55 ` Bart.Vanhauwaert 2001-08-08 2:59 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 875+ messages in thread From: James Rogers @ 2001-08-07 22:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 22:44 ` James Rogers @ 2001-08-08 4:04 ` Lao Xiao Hai 2001-08-08 10:00 ` Ole-Hjalmar Kristensen 2001-08-08 21:55 ` Bart.Vanhauwaert 1 sibling, 1 reply; 875+ messages in thread From: Lao Xiao Hai @ 2001-08-08 4:04 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:04 ` Lao Xiao Hai @ 2001-08-08 10:00 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 875+ messages in thread From: Ole-Hjalmar Kristensen @ 2001-08-08 10:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 22:44 ` James Rogers 2001-08-08 4:04 ` Lao Xiao Hai @ 2001-08-08 21:55 ` Bart.Vanhauwaert 2001-08-08 23:13 ` Larry Kilgallen 2001-08-09 13:20 ` Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-08 21:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 21:55 ` Bart.Vanhauwaert @ 2001-08-08 23:13 ` Larry Kilgallen 2001-08-09 13:20 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-08 23:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 21:55 ` Bart.Vanhauwaert 2001-08-08 23:13 ` Larry Kilgallen @ 2001-08-09 13:20 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-09 13:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 11:57 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 2001-08-07 22:44 ` James Rogers @ 2001-08-08 2:59 ` Warren W. Gay VE3WWG 2001-08-08 4:03 ` David Bolen 2001-08-08 22:18 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 1 sibling, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-08 2:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 2:59 ` Warren W. Gay VE3WWG @ 2001-08-08 4:03 ` David Bolen 2001-08-08 4:56 ` Warren W. Gay VE3WWG 2001-08-08 22:18 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 1 sibling, 1 reply; 875+ messages in thread From: David Bolen @ 2001-08-08 4:03 UTC (permalink / raw) "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 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:03 ` David Bolen @ 2001-08-08 4:56 ` Warren W. Gay VE3WWG 2001-08-08 23:49 ` David Bolen 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-08 4:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:56 ` Warren W. Gay VE3WWG @ 2001-08-08 23:49 ` David Bolen 2001-08-09 5:12 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: David Bolen @ 2001-08-08 23:49 UTC (permalink / raw) "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 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 23:49 ` David Bolen @ 2001-08-09 5:12 ` Warren W. Gay VE3WWG 2001-08-09 13:10 ` How Ada could have prevented the Red Code distributed denial Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-09 5:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial 2001-08-09 5:12 ` Warren W. Gay VE3WWG @ 2001-08-09 13:10 ` Ted Dennison 2001-08-09 23:57 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-09 13:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial 2001-08-09 13:10 ` How Ada could have prevented the Red Code distributed denial Ted Dennison @ 2001-08-09 23:57 ` Warren W. Gay VE3WWG 2001-08-10 13:35 ` Data portability with streams Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-09 23:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Data portability with streams 2001-08-09 23:57 ` Warren W. Gay VE3WWG @ 2001-08-10 13:35 ` Ted Dennison 2001-08-10 17:13 ` Robert Dewar 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-10 13:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Data portability with streams 2001-08-10 13:35 ` Data portability with streams Ted Dennison @ 2001-08-10 17:13 ` Robert Dewar 2001-08-10 19:51 ` Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: Robert Dewar @ 2001-08-10 17:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Data portability with streams 2001-08-10 17:13 ` Robert Dewar @ 2001-08-10 19:51 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-10 19:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 2:59 ` Warren W. Gay VE3WWG 2001-08-08 4:03 ` David Bolen @ 2001-08-08 22:18 ` Bart.Vanhauwaert 2001-08-09 5:30 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-08 22:18 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 22:18 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert @ 2001-08-09 5:30 ` Warren W. Gay VE3WWG 2001-08-09 18:10 ` Bart.Vanhauwaert ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-09 5:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 5:30 ` Warren W. Gay VE3WWG @ 2001-08-09 18:10 ` Bart.Vanhauwaert 2001-08-10 0:05 ` Warren W. Gay VE3WWG 2001-08-14 12:51 ` Bertrand Augereau 2001-08-16 5:16 ` David Thompson 2 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-09 18:10 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 18:10 ` Bart.Vanhauwaert @ 2001-08-10 0:05 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-10 0:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 5:30 ` Warren W. Gay VE3WWG 2001-08-09 18:10 ` Bart.Vanhauwaert @ 2001-08-14 12:51 ` Bertrand Augereau 2001-08-14 13:32 ` Bertrand Augereau ` (3 more replies) 2001-08-16 5:16 ` David Thompson 2 siblings, 4 replies; 875+ messages in thread From: Bertrand Augereau @ 2001-08-14 12:51 UTC (permalink / raw) > 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 12:51 ` Bertrand Augereau @ 2001-08-14 13:32 ` Bertrand Augereau 2001-08-14 14:39 ` Larry Hazel ` (2 subsequent siblings) 3 siblings, 0 replies; 875+ messages in thread From: Bertrand Augereau @ 2001-08-14 13:32 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 12:51 ` Bertrand Augereau 2001-08-14 13:32 ` Bertrand Augereau @ 2001-08-14 14:39 ` Larry Hazel 2001-08-14 16:14 ` Kaz Kylheku 2001-08-14 16:15 ` Warren W. Gay VE3WWG 3 siblings, 0 replies; 875+ messages in thread From: Larry Hazel @ 2001-08-14 14:39 UTC (permalink / raw) Bertrand Augereau wrote: > But you Ada programmers like it verbose, don't you ;-) > Nope - readable and correct. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 12:51 ` Bertrand Augereau 2001-08-14 13:32 ` Bertrand Augereau 2001-08-14 14:39 ` Larry Hazel @ 2001-08-14 16:14 ` Kaz Kylheku 2001-08-14 16:26 ` Bertrand Augereau 2001-08-15 13:36 ` Martin 2001-08-14 16:15 ` Warren W. Gay VE3WWG 3 siblings, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-14 16:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 16:14 ` Kaz Kylheku @ 2001-08-14 16:26 ` Bertrand Augereau 2001-08-15 13:36 ` Martin 1 sibling, 0 replies; 875+ messages in thread From: Bertrand Augereau @ 2001-08-14 16:26 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 16:14 ` Kaz Kylheku 2001-08-14 16:26 ` Bertrand Augereau @ 2001-08-15 13:36 ` Martin 2001-08-15 16:47 ` Ray Blaak 1 sibling, 1 reply; 875+ messages in thread From: Martin @ 2001-08-15 13:36 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-15 13:36 ` Martin @ 2001-08-15 16:47 ` Ray Blaak 0 siblings, 0 replies; 875+ messages in thread From: Ray Blaak @ 2001-08-15 16:47 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 12:51 ` Bertrand Augereau ` (2 preceding siblings ...) 2001-08-14 16:14 ` Kaz Kylheku @ 2001-08-14 16:15 ` Warren W. Gay VE3WWG 3 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-14 16:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 5:30 ` Warren W. Gay VE3WWG 2001-08-09 18:10 ` Bart.Vanhauwaert 2001-08-14 12:51 ` Bertrand Augereau @ 2001-08-16 5:16 ` David Thompson 2001-08-16 13:19 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 875+ messages in thread From: David Thompson @ 2001-08-16 5:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 5:16 ` David Thompson @ 2001-08-16 13:19 ` Warren W. Gay VE3WWG 2001-08-16 13:25 ` Richard Bos ` (5 more replies) 0 siblings, 6 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-16 13:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 13:19 ` Warren W. Gay VE3WWG @ 2001-08-16 13:25 ` Richard Bos 2001-08-16 13:44 ` Ian Wild ` (4 subsequent siblings) 5 siblings, 0 replies; 875+ messages in thread From: Richard Bos @ 2001-08-16 13:25 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 13:19 ` Warren W. Gay VE3WWG 2001-08-16 13:25 ` Richard Bos @ 2001-08-16 13:44 ` Ian Wild 2001-08-16 17:32 ` Warren W. Gay VE3WWG 2001-08-16 17:31 ` Kaz Kylheku ` (3 subsequent siblings) 5 siblings, 1 reply; 875+ messages in thread From: Ian Wild @ 2001-08-16 13:44 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 13:44 ` Ian Wild @ 2001-08-16 17:32 ` Warren W. Gay VE3WWG 2001-08-16 17:53 ` Kaz Kylheku 2001-08-16 18:23 ` Ron Natalie 0 siblings, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-16 17:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 17:32 ` Warren W. Gay VE3WWG @ 2001-08-16 17:53 ` Kaz Kylheku 2001-08-16 18:52 ` David C. Hoos 2001-08-16 20:40 ` Warren W. Gay VE3WWG 2001-08-16 18:23 ` Ron Natalie 1 sibling, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-16 17:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 17:53 ` Kaz Kylheku @ 2001-08-16 18:52 ` David C. Hoos 2001-08-16 20:40 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: David C. Hoos @ 2001-08-16 18:52 UTC (permalink / raw) To: comp.lang.ada; +Cc: kaz ----- 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!! ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 17:53 ` Kaz Kylheku 2001-08-16 18:52 ` David C. Hoos @ 2001-08-16 20:40 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-16 20:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 17:32 ` Warren W. Gay VE3WWG 2001-08-16 17:53 ` Kaz Kylheku @ 2001-08-16 18:23 ` Ron Natalie 2001-08-16 20:41 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 875+ messages in thread From: Ron Natalie @ 2001-08-16 18:23 UTC (permalink / raw) = > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 18:23 ` Ron Natalie @ 2001-08-16 20:41 ` Warren W. Gay VE3WWG 2001-08-16 21:14 ` Ben Pfaff 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-16 20:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 20:41 ` Warren W. Gay VE3WWG @ 2001-08-16 21:14 ` Ben Pfaff 2001-08-16 21:33 ` Ron Natalie 2001-08-16 21:34 ` Karthik Gurusamy 0 siblings, 2 replies; 875+ messages in thread From: Ben Pfaff @ 2001-08-16 21:14 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 21:14 ` Ben Pfaff @ 2001-08-16 21:33 ` Ron Natalie 2001-08-17 18:10 ` Warren W. Gay VE3WWG 2001-08-16 21:34 ` Karthik Gurusamy 1 sibling, 1 reply; 875+ messages in thread From: Ron Natalie @ 2001-08-16 21:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 21:33 ` Ron Natalie @ 2001-08-17 18:10 ` Warren W. Gay VE3WWG 2001-08-20 8:22 ` Ian Wild 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-17 18:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 18:10 ` Warren W. Gay VE3WWG @ 2001-08-20 8:22 ` Ian Wild 0 siblings, 0 replies; 875+ messages in thread From: Ian Wild @ 2001-08-20 8:22 UTC (permalink / raw) "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... ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 21:14 ` Ben Pfaff 2001-08-16 21:33 ` Ron Natalie @ 2001-08-16 21:34 ` Karthik Gurusamy 2001-08-16 21:36 ` Ben Pfaff 1 sibling, 1 reply; 875+ messages in thread From: Karthik Gurusamy @ 2001-08-16 21:34 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 21:34 ` Karthik Gurusamy @ 2001-08-16 21:36 ` Ben Pfaff 0 siblings, 0 replies; 875+ messages in thread From: Ben Pfaff @ 2001-08-16 21:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 13:19 ` Warren W. Gay VE3WWG 2001-08-16 13:25 ` Richard Bos 2001-08-16 13:44 ` Ian Wild @ 2001-08-16 17:31 ` Kaz Kylheku 2001-08-16 19:28 ` Samuel T. Harris 2001-08-19 18:14 ` Michael Rubenstein 2001-08-16 18:28 ` Clark S. Cox III ` (2 subsequent siblings) 5 siblings, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-16 17:31 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 17:31 ` Kaz Kylheku @ 2001-08-16 19:28 ` Samuel T. Harris 2001-08-19 18:14 ` Michael Rubenstein 1 sibling, 0 replies; 875+ messages in thread From: Samuel T. Harris @ 2001-08-16 19:28 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 17:31 ` Kaz Kylheku 2001-08-16 19:28 ` Samuel T. Harris @ 2001-08-19 18:14 ` Michael Rubenstein 1 sibling, 0 replies; 875+ messages in thread From: Michael Rubenstein @ 2001-08-19 18:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 13:19 ` Warren W. Gay VE3WWG ` (2 preceding siblings ...) 2001-08-16 17:31 ` Kaz Kylheku @ 2001-08-16 18:28 ` Clark S. Cox III [not found] ` <urTe7.71343$B37.16278 <3B7C1EF2.4DF3C7A5@gsde.hou.us.ray.com> [not found] ` <3B7BCEC4.202A3FA@cfmu <Pine.GSO.4.33.0108161431560.15612-100000@longmorn.cisco.com> 5 siblings, 0 replies; 875+ messages in thread From: Clark S. Cox III @ 2001-08-16 18:28 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <urTe7.71343$B37.16278 <3B7C1EF2.4DF3C7A5@gsde.hou.us.ray.com>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <urTe7.71343$B37.16278 <3B7C1EF2.4DF3C7A5@gsde.hou.us.ray.com> @ 2001-08-16 21:49 ` Greg Comeau 2001-08-16 22:38 ` Samuel T. Harris 0 siblings, 1 reply; 875+ messages in thread From: Greg Comeau @ 2001-08-16 21:49 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 21:49 ` Greg Comeau @ 2001-08-16 22:38 ` Samuel T. Harris 0 siblings, 0 replies; 875+ messages in thread From: Samuel T. Harris @ 2001-08-16 22:38 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <3B7BCEC4.202A3FA@cfmu <Pine.GSO.4.33.0108161431560.15612-100000@longmorn.cisco.com>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <3B7BCEC4.202A3FA@cfmu <Pine.GSO.4.33.0108161431560.15612-100000@longmorn.cisco.com> @ 2001-08-16 22:23 ` Greg Comeau 0 siblings, 0 replies; 875+ messages in thread From: Greg Comeau @ 2001-08-16 22:23 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:07 ` Warren W. Gay VE3WWG 2001-08-07 0:15 ` Kaz Kylheku 2001-08-07 11:57 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert @ 2001-08-13 20:54 ` Stefan Skoglund 2 siblings, 0 replies; 875+ messages in thread From: Stefan Skoglund @ 2001-08-13 20:54 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 21:26 ` Bart.Vanhauwaert 2001-08-07 0:07 ` Warren W. Gay VE3WWG @ 2001-08-07 16:20 ` Ted Dennison 2001-08-07 17:49 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-07 16:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 16:20 ` Ted Dennison @ 2001-08-07 17:49 ` Marin David Condic 2001-08-08 3:14 ` Warren W. Gay VE3WWG 2001-08-08 22:34 ` Bart.Vanhauwaert 0 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-07 17:49 UTC (permalink / raw) 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. :-) > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 17:49 ` Marin David Condic @ 2001-08-08 3:14 ` Warren W. Gay VE3WWG 2001-08-08 22:34 ` Bart.Vanhauwaert 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-08 3:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 17:49 ` Marin David Condic 2001-08-08 3:14 ` Warren W. Gay VE3WWG @ 2001-08-08 22:34 ` Bart.Vanhauwaert 2001-08-09 5:36 ` Warren W. Gay VE3WWG 2001-08-09 14:18 ` Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-08 22:34 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 22:34 ` Bart.Vanhauwaert @ 2001-08-09 5:36 ` Warren W. Gay VE3WWG 2001-08-09 18:43 ` Bart.Vanhauwaert 2001-08-09 14:18 ` Ted Dennison 1 sibling, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-09 5:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 5:36 ` Warren W. Gay VE3WWG @ 2001-08-09 18:43 ` Bart.Vanhauwaert 2001-08-10 0:23 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-09 18:43 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 18:43 ` Bart.Vanhauwaert @ 2001-08-10 0:23 ` Warren W. Gay VE3WWG 2001-08-10 12:29 ` Bart.Vanhauwaert 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-10 0:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 0:23 ` Warren W. Gay VE3WWG @ 2001-08-10 12:29 ` Bart.Vanhauwaert 2001-08-10 15:01 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-10 12:29 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 12:29 ` Bart.Vanhauwaert @ 2001-08-10 15:01 ` Warren W. Gay VE3WWG 2001-08-11 9:00 ` Bart.Vanhauwaert 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-10 15:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 15:01 ` Warren W. Gay VE3WWG @ 2001-08-11 9:00 ` Bart.Vanhauwaert 2001-08-11 18:19 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-11 9:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-11 9:00 ` Bart.Vanhauwaert @ 2001-08-11 18:19 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-11 18:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 22:34 ` Bart.Vanhauwaert 2001-08-09 5:36 ` Warren W. Gay VE3WWG @ 2001-08-09 14:18 ` Ted Dennison 2001-08-09 15:48 ` Clark S. Cox III 2001-08-09 19:07 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 1 sibling, 2 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-09 14:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 14:18 ` Ted Dennison @ 2001-08-09 15:48 ` Clark S. Cox III 2001-08-09 16:52 ` Ted Dennison 2001-08-09 19:07 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 1 sibling, 1 reply; 875+ messages in thread From: Clark S. Cox III @ 2001-08-09 15:48 UTC (permalink / raw) [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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 15:48 ` Clark S. Cox III @ 2001-08-09 16:52 ` Ted Dennison 2001-08-09 17:34 ` Clark S. Cox III ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-09 16:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 16:52 ` Ted Dennison @ 2001-08-09 17:34 ` Clark S. Cox III 2001-08-09 19:23 ` Bart.Vanhauwaert 2001-08-09 20:26 ` Florian Weimer 2 siblings, 0 replies; 875+ messages in thread From: Clark S. Cox III @ 2001-08-09 17:34 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 16:52 ` Ted Dennison 2001-08-09 17:34 ` Clark S. Cox III @ 2001-08-09 19:23 ` Bart.Vanhauwaert 2001-08-13 21:59 ` Stefan Skoglund 2001-08-09 20:26 ` Florian Weimer 2 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-09 19:23 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:23 ` Bart.Vanhauwaert @ 2001-08-13 21:59 ` Stefan Skoglund 2001-08-20 13:39 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Stefan Skoglund @ 2001-08-13 21:59 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-13 21:59 ` Stefan Skoglund @ 2001-08-20 13:39 ` Marin David Condic 2001-08-23 17:17 ` Stefan Skoglund 2001-08-27 1:49 ` simple CPUs, was " tmoran 0 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-20 13:39 UTC (permalink / raw) 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 ? > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-20 13:39 ` Marin David Condic @ 2001-08-23 17:17 ` Stefan Skoglund 2001-08-27 1:49 ` simple CPUs, was " tmoran 1 sibling, 0 replies; 875+ messages in thread From: Stefan Skoglund @ 2001-08-23 17:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-20 13:39 ` Marin David Condic 2001-08-23 17:17 ` Stefan Skoglund @ 2001-08-27 1:49 ` tmoran 2001-08-27 11:08 ` Florian Weimer 2001-08-27 13:53 ` Marin David Condic 1 sibling, 2 replies; 875+ messages in thread From: tmoran @ 2001-08-27 1:49 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 1:49 ` simple CPUs, was " tmoran @ 2001-08-27 11:08 ` Florian Weimer 2001-08-27 13:53 ` Marin David Condic 1 sibling, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-27 11:08 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 1:49 ` simple CPUs, was " tmoran 2001-08-27 11:08 ` Florian Weimer @ 2001-08-27 13:53 ` Marin David Condic 2001-08-27 14:44 ` Gary Scott 2001-08-27 18:46 ` tmoran 1 sibling, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-27 13:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 13:53 ` Marin David Condic @ 2001-08-27 14:44 ` Gary Scott 2001-08-27 18:49 ` Marin David Condic 2001-08-27 18:46 ` tmoran 1 sibling, 1 reply; 875+ messages in thread From: Gary Scott @ 2001-08-27 14:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 14:44 ` Gary Scott @ 2001-08-27 18:49 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-27 18:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 13:53 ` Marin David Condic 2001-08-27 14:44 ` Gary Scott @ 2001-08-27 18:46 ` tmoran 2001-08-27 19:10 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: tmoran @ 2001-08-27 18:46 UTC (permalink / raw) > 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? :) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 18:46 ` tmoran @ 2001-08-27 19:10 ` Marin David Condic 2001-08-27 23:33 ` William Dale 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-27 19:10 UTC (permalink / raw) 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? :) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 19:10 ` Marin David Condic @ 2001-08-27 23:33 ` William Dale 2001-08-28 13:38 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: William Dale @ 2001-08-27 23:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-27 23:33 ` William Dale @ 2001-08-28 13:38 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-28 13:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 16:52 ` Ted Dennison 2001-08-09 17:34 ` Clark S. Cox III 2001-08-09 19:23 ` Bart.Vanhauwaert @ 2001-08-09 20:26 ` Florian Weimer 2001-08-09 21:03 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2 siblings, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-08-09 20:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-09 20:26 ` Florian Weimer @ 2001-08-09 21:03 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-09 21:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 14:18 ` Ted Dennison 2001-08-09 15:48 ` Clark S. Cox III @ 2001-08-09 19:07 ` Bart.Vanhauwaert 2001-08-10 1:05 ` Warren W. Gay VE3WWG 2001-08-10 14:16 ` Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-09 19:07 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:07 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert @ 2001-08-10 1:05 ` Warren W. Gay VE3WWG 2001-08-10 12:45 ` Bart.Vanhauwaert 2001-08-14 13:09 ` Bertrand Augereau 2001-08-10 14:16 ` Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-10 1:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 1:05 ` Warren W. Gay VE3WWG @ 2001-08-10 12:45 ` Bart.Vanhauwaert 2001-08-10 15:05 ` Warren W. Gay VE3WWG 2001-08-14 13:09 ` Bertrand Augereau 1 sibling, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-10 12:45 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 12:45 ` Bart.Vanhauwaert @ 2001-08-10 15:05 ` Warren W. Gay VE3WWG 2001-08-11 9:05 ` Bart.Vanhauwaert 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-10 15:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 15:05 ` Warren W. Gay VE3WWG @ 2001-08-11 9:05 ` Bart.Vanhauwaert 2001-08-11 19:49 ` Matthew Woodcraft 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-11 9:05 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-11 9:05 ` Bart.Vanhauwaert @ 2001-08-11 19:49 ` Matthew Woodcraft 0 siblings, 0 replies; 875+ messages in thread From: Matthew Woodcraft @ 2001-08-11 19:49 UTC (permalink / raw) 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- ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 1:05 ` Warren W. Gay VE3WWG 2001-08-10 12:45 ` Bart.Vanhauwaert @ 2001-08-14 13:09 ` Bertrand Augereau 2001-08-17 0:46 ` Warren W. Gay VE3WWG 2001-08-17 17:11 ` How Ada could have prevented the Red Code distributed denial of service attack Matthew Austern 1 sibling, 2 replies; 875+ messages in thread From: Bertrand Augereau @ 2001-08-14 13:09 UTC (permalink / raw) [-- 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*. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 13:09 ` Bertrand Augereau @ 2001-08-17 0:46 ` Warren W. Gay VE3WWG 2001-08-17 1:53 ` Kaz Kylheku 2001-08-17 1:57 ` Chris Wolfe 2001-08-17 17:11 ` How Ada could have prevented the Red Code distributed denial of service attack Matthew Austern 1 sibling, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-17 0:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 0:46 ` Warren W. Gay VE3WWG @ 2001-08-17 1:53 ` Kaz Kylheku 2001-08-17 9:29 ` pete 2001-08-17 1:57 ` Chris Wolfe 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-17 1:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 1:53 ` Kaz Kylheku @ 2001-08-17 9:29 ` pete 2001-08-17 10:23 ` Richard Bos 2001-08-17 20:12 ` Kaz Kylheku 0 siblings, 2 replies; 875+ messages in thread From: pete @ 2001-08-17 9:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 9:29 ` pete @ 2001-08-17 10:23 ` Richard Bos 2001-08-17 13:46 ` pete 2001-08-17 14:33 ` pete 2001-08-17 20:12 ` Kaz Kylheku 1 sibling, 2 replies; 875+ messages in thread From: Richard Bos @ 2001-08-17 10:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 10:23 ` Richard Bos @ 2001-08-17 13:46 ` pete 2001-08-17 14:33 ` pete 1 sibling, 0 replies; 875+ messages in thread From: pete @ 2001-08-17 13:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 10:23 ` Richard Bos 2001-08-17 13:46 ` pete @ 2001-08-17 14:33 ` pete 1 sibling, 0 replies; 875+ messages in thread From: pete @ 2001-08-17 14:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 9:29 ` pete 2001-08-17 10:23 ` Richard Bos @ 2001-08-17 20:12 ` Kaz Kylheku 2001-08-20 7:02 ` pete 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-17 20:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 20:12 ` Kaz Kylheku @ 2001-08-20 7:02 ` pete 2001-08-20 16:39 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: pete @ 2001-08-20 7:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-20 7:02 ` pete @ 2001-08-20 16:39 ` Kaz Kylheku 0 siblings, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-20 16:39 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 0:46 ` Warren W. Gay VE3WWG 2001-08-17 1:53 ` Kaz Kylheku @ 2001-08-17 1:57 ` Chris Wolfe 2001-08-17 2:27 ` Kaz Kylheku 2001-08-17 14:05 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Chris Wolfe @ 2001-08-17 1:57 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 1:57 ` Chris Wolfe @ 2001-08-17 2:27 ` Kaz Kylheku 2001-08-17 3:42 ` Warren W. Gay VE3WWG 2001-08-17 14:05 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-17 2:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 2:27 ` Kaz Kylheku @ 2001-08-17 3:42 ` Warren W. Gay VE3WWG 2001-08-17 7:33 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-17 3:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 3:42 ` Warren W. Gay VE3WWG @ 2001-08-17 7:33 ` Kaz Kylheku 2001-08-17 13:46 ` Warren W. Gay VE3WWG 2001-08-17 16:40 ` Ian 0 siblings, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-17 7:33 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 7:33 ` Kaz Kylheku @ 2001-08-17 13:46 ` Warren W. Gay VE3WWG 2001-08-17 20:08 ` Kaz Kylheku 2001-08-19 21:19 ` Bart.Vanhauwaert 2001-08-17 16:40 ` Ian 1 sibling, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-17 13:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 13:46 ` Warren W. Gay VE3WWG @ 2001-08-17 20:08 ` Kaz Kylheku 2001-08-18 5:16 ` Warren W. Gay VE3WWG 2001-08-19 21:19 ` Bart.Vanhauwaert 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-17 20:08 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 20:08 ` Kaz Kylheku @ 2001-08-18 5:16 ` Warren W. Gay VE3WWG 2001-08-18 22:27 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-18 5:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-18 5:16 ` Warren W. Gay VE3WWG @ 2001-08-18 22:27 ` Kaz Kylheku 2001-08-29 3:47 ` David Thompson 0 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-18 22:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-18 22:27 ` Kaz Kylheku @ 2001-08-29 3:47 ` David Thompson 2001-08-29 16:00 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: David Thompson @ 2001-08-29 3:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-29 3:47 ` David Thompson @ 2001-08-29 16:00 ` Kaz Kylheku 0 siblings, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-29 16:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 13:46 ` Warren W. Gay VE3WWG 2001-08-17 20:08 ` Kaz Kylheku @ 2001-08-19 21:19 ` Bart.Vanhauwaert 1 sibling, 0 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-19 21:19 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-17 7:33 ` Kaz Kylheku 2001-08-17 13:46 ` Warren W. Gay VE3WWG @ 2001-08-17 16:40 ` Ian 1 sibling, 0 replies; 875+ messages in thread From: Ian @ 2001-08-17 16:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-17 1:57 ` Chris Wolfe 2001-08-17 2:27 ` Kaz Kylheku @ 2001-08-17 14:05 ` Ted Dennison 2001-08-17 22:15 ` Chris Wolfe 1 sibling, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-17 14:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-17 14:05 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison @ 2001-08-17 22:15 ` Chris Wolfe 0 siblings, 0 replies; 875+ messages in thread From: Chris Wolfe @ 2001-08-17 22:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-14 13:09 ` Bertrand Augereau 2001-08-17 0:46 ` Warren W. Gay VE3WWG @ 2001-08-17 17:11 ` Matthew Austern 1 sibling, 0 replies; 875+ messages in thread From: Matthew Austern @ 2001-08-17 17:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:07 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 2001-08-10 1:05 ` Warren W. Gay VE3WWG @ 2001-08-10 14:16 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-10 14:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 16:10 ` Dan Cross 2001-08-02 16:20 ` Daniel Fischer @ 2001-08-03 7:26 ` Richard Bos 2001-08-03 15:05 ` Dan Cross 2001-08-06 18:55 ` Bart.Vanhauwaert 2 siblings, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-03 7:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 7:26 ` Richard Bos @ 2001-08-03 15:05 ` Dan Cross 2001-08-03 18:06 ` Preben Randhol 2001-08-06 10:04 ` Richard Bos 0 siblings, 2 replies; 875+ messages in thread From: Dan Cross @ 2001-08-03 15:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 15:05 ` Dan Cross @ 2001-08-03 18:06 ` Preben Randhol 2001-08-03 19:05 ` Dan Cross ` (2 more replies) 2001-08-06 10:04 ` Richard Bos 1 sibling, 3 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-03 18:06 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 18:06 ` Preben Randhol @ 2001-08-03 19:05 ` Dan Cross 2001-08-03 19:37 ` Mark Wilden 2001-08-03 19:56 ` How Ada could have prevented the Red Code distributed denial of service attack Ted Dennison 2 siblings, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-03 19:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 18:06 ` Preben Randhol 2001-08-03 19:05 ` Dan Cross @ 2001-08-03 19:37 ` Mark Wilden 2001-08-04 8:00 ` Preben Randhol 2001-08-03 19:56 ` How Ada could have prevented the Red Code distributed denial of service attack Ted Dennison 2 siblings, 1 reply; 875+ messages in thread From: Mark Wilden @ 2001-08-03 19:37 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 19:37 ` Mark Wilden @ 2001-08-04 8:00 ` Preben Randhol 2001-08-06 16:48 ` Mark Wilden 0 siblings, 1 reply; 875+ messages in thread From: Preben Randhol @ 2001-08-04 8:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 8:00 ` Preben Randhol @ 2001-08-06 16:48 ` Mark Wilden 2001-08-06 16:56 ` Preben Randhol 0 siblings, 1 reply; 875+ messages in thread From: Mark Wilden @ 2001-08-06 16:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 16:48 ` Mark Wilden @ 2001-08-06 16:56 ` Preben Randhol 2001-08-06 17:16 ` Gerhard Häring ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-06 16:56 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 16:56 ` Preben Randhol @ 2001-08-06 17:16 ` Gerhard Häring 2001-08-06 17:34 ` Kaz Kylheku [not found] ` <QyAb7.24745$B37.4 <87zo9dug9p.fsf@pfaffben.user.msu.edu> 2001-08-06 17:19 ` Mark Wilden 2001-08-07 0:10 ` Warren W. Gay VE3WWG 2 siblings, 2 replies; 875+ messages in thread From: Gerhard Häring @ 2001-08-06 17:16 UTC (permalink / raw) 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')]) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 17:16 ` Gerhard Häring @ 2001-08-06 17:34 ` Kaz Kylheku 2001-08-06 19:30 ` Preben Randhol [not found] ` <QyAb7.24745$B37.4 <87zo9dug9p.fsf@pfaffben.user.msu.edu> 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-06 17:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 17:34 ` Kaz Kylheku @ 2001-08-06 19:30 ` Preben Randhol 2001-08-06 19:42 ` Ben Pfaff 0 siblings, 1 reply; 875+ messages in thread From: Preben Randhol @ 2001-08-06 19:30 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 19:30 ` Preben Randhol @ 2001-08-06 19:42 ` Ben Pfaff 2001-08-06 22:52 ` Preben Randhol 0 siblings, 1 reply; 875+ messages in thread From: Ben Pfaff @ 2001-08-06 19:42 UTC (permalink / raw) [-- 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 19:42 ` Ben Pfaff @ 2001-08-06 22:52 ` Preben Randhol 0 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-06 22:52 UTC (permalink / raw) 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?� ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <QyAb7.24745$B37.4 <87zo9dug9p.fsf@pfaffben.user.msu.edu>]
* Re: How Ada could have prevented the Red Code distributed denial of service attack. [not found] ` <QyAb7.24745$B37.4 <87zo9dug9p.fsf@pfaffben.user.msu.edu> @ 2001-08-06 21:08 ` Dan Cross 2001-08-06 21:28 ` Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-06 21:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 21:08 ` Dan Cross @ 2001-08-06 21:28 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-06 21:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 16:56 ` Preben Randhol 2001-08-06 17:16 ` Gerhard Häring @ 2001-08-06 17:19 ` Mark Wilden 2001-08-06 19:19 ` Preben Randhol 2001-08-07 0:10 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 875+ messages in thread From: Mark Wilden @ 2001-08-06 17:19 UTC (permalink / raw) "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? :) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 17:19 ` Mark Wilden @ 2001-08-06 19:19 ` Preben Randhol 0 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-06 19:19 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 16:56 ` Preben Randhol 2001-08-06 17:16 ` Gerhard Häring 2001-08-06 17:19 ` Mark Wilden @ 2001-08-07 0:10 ` Warren W. Gay VE3WWG 2001-08-07 1:09 ` Chris Wolfe ` (5 more replies) 2 siblings, 6 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-07 0:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:10 ` Warren W. Gay VE3WWG @ 2001-08-07 1:09 ` Chris Wolfe 2001-08-07 3:06 ` James Rogers 2001-08-07 3:09 ` Warren W. Gay VE3WWG 2001-08-07 7:09 ` How Ada could have prevented the Red Code distributed denial of service attack Chris Torek ` (4 subsequent siblings) 5 siblings, 2 replies; 875+ messages in thread From: Chris Wolfe @ 2001-08-07 1:09 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 1:09 ` Chris Wolfe @ 2001-08-07 3:06 ` James Rogers 2001-08-07 6:11 ` Kaz Kylheku ` (3 more replies) 2001-08-07 3:09 ` Warren W. Gay VE3WWG 1 sibling, 4 replies; 875+ messages in thread From: James Rogers @ 2001-08-07 3:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:06 ` James Rogers @ 2001-08-07 6:11 ` Kaz Kylheku 2001-08-07 23:22 ` James Rogers 2001-08-07 7:25 ` Kaz Kylheku ` (2 subsequent siblings) 3 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-07 6:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 6:11 ` Kaz Kylheku @ 2001-08-07 23:22 ` James Rogers 2001-08-08 0:25 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: James Rogers @ 2001-08-07 23:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 23:22 ` James Rogers @ 2001-08-08 0:25 ` Kaz Kylheku 2001-08-08 14:03 ` Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-08 0:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 0:25 ` Kaz Kylheku @ 2001-08-08 14:03 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-08 14:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:06 ` James Rogers 2001-08-07 6:11 ` Kaz Kylheku @ 2001-08-07 7:25 ` Kaz Kylheku 2001-08-07 23:24 ` James Rogers 2001-08-07 11:05 ` Daniel Fischer 2001-08-07 23:20 ` Chris Wolfe 3 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-07 7:25 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 7:25 ` Kaz Kylheku @ 2001-08-07 23:24 ` James Rogers 0 siblings, 0 replies; 875+ messages in thread From: James Rogers @ 2001-08-07 23:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:06 ` James Rogers 2001-08-07 6:11 ` Kaz Kylheku 2001-08-07 7:25 ` Kaz Kylheku @ 2001-08-07 11:05 ` Daniel Fischer 2001-08-07 23:20 ` Chris Wolfe 3 siblings, 0 replies; 875+ messages in thread From: Daniel Fischer @ 2001-08-07 11:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:06 ` James Rogers ` (2 preceding siblings ...) 2001-08-07 11:05 ` Daniel Fischer @ 2001-08-07 23:20 ` Chris Wolfe 2001-08-07 23:32 ` Chris Wolfe 2001-08-08 4:52 ` James Rogers 3 siblings, 2 replies; 875+ messages in thread From: Chris Wolfe @ 2001-08-07 23:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 23:20 ` Chris Wolfe @ 2001-08-07 23:32 ` Chris Wolfe 2001-08-08 4:52 ` James Rogers 1 sibling, 0 replies; 875+ messages in thread From: Chris Wolfe @ 2001-08-07 23:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 23:20 ` Chris Wolfe 2001-08-07 23:32 ` Chris Wolfe @ 2001-08-08 4:52 ` James Rogers 2001-08-08 5:31 ` Kaz Kylheku ` (3 more replies) 1 sibling, 4 replies; 875+ messages in thread From: James Rogers @ 2001-08-08 4:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:52 ` James Rogers @ 2001-08-08 5:31 ` Kaz Kylheku 2001-08-08 5:36 ` Kaz Kylheku ` (2 subsequent siblings) 3 siblings, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-08 5:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:52 ` James Rogers 2001-08-08 5:31 ` Kaz Kylheku @ 2001-08-08 5:36 ` Kaz Kylheku 2001-08-08 12:26 ` James Rogers 2001-08-08 14:47 ` Ted Dennison 2001-08-08 9:27 ` Ole-Hjalmar Kristensen 2001-08-08 23:08 ` Chris Wolfe 3 siblings, 2 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-08 5:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 5:36 ` Kaz Kylheku @ 2001-08-08 12:26 ` James Rogers 2001-08-08 14:47 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: James Rogers @ 2001-08-08 12:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 5:36 ` Kaz Kylheku 2001-08-08 12:26 ` James Rogers @ 2001-08-08 14:47 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-08 14:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:52 ` James Rogers 2001-08-08 5:31 ` Kaz Kylheku 2001-08-08 5:36 ` Kaz Kylheku @ 2001-08-08 9:27 ` Ole-Hjalmar Kristensen 2001-08-08 23:08 ` Chris Wolfe 3 siblings, 0 replies; 875+ messages in thread From: Ole-Hjalmar Kristensen @ 2001-08-08 9:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:52 ` James Rogers ` (2 preceding siblings ...) 2001-08-08 9:27 ` Ole-Hjalmar Kristensen @ 2001-08-08 23:08 ` Chris Wolfe 3 siblings, 0 replies; 875+ messages in thread From: Chris Wolfe @ 2001-08-08 23:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 1:09 ` Chris Wolfe 2001-08-07 3:06 ` James Rogers @ 2001-08-07 3:09 ` Warren W. Gay VE3WWG 2001-08-07 22:01 ` Chris Wolfe 1 sibling, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-07 3:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 3:09 ` Warren W. Gay VE3WWG @ 2001-08-07 22:01 ` Chris Wolfe 2001-08-08 4:18 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Chris Wolfe @ 2001-08-07 22:01 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 22:01 ` Chris Wolfe @ 2001-08-08 4:18 ` Warren W. Gay VE3WWG 2001-08-08 5:00 ` Kaz Kylheku 2001-08-08 23:12 ` Chris Wolfe 0 siblings, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-08 4:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:18 ` Warren W. Gay VE3WWG @ 2001-08-08 5:00 ` Kaz Kylheku 2001-08-08 5:16 ` Warren W. Gay VE3WWG 2001-08-08 23:12 ` Chris Wolfe 1 sibling, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-08 5:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 5:00 ` Kaz Kylheku @ 2001-08-08 5:16 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-08 5:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 4:18 ` Warren W. Gay VE3WWG 2001-08-08 5:00 ` Kaz Kylheku @ 2001-08-08 23:12 ` Chris Wolfe 2001-08-08 23:44 ` Ed Falis ` (2 more replies) 1 sibling, 3 replies; 875+ messages in thread From: Chris Wolfe @ 2001-08-08 23:12 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 23:12 ` Chris Wolfe @ 2001-08-08 23:44 ` Ed Falis 2001-08-09 0:19 ` Chris Wolfe 2001-08-09 3:15 ` Kaz Kylheku 2001-08-09 5:48 ` Warren W. Gay VE3WWG 2001-08-09 14:48 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2 siblings, 2 replies; 875+ messages in thread From: Ed Falis @ 2001-08-08 23:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 23:44 ` Ed Falis @ 2001-08-09 0:19 ` Chris Wolfe 2001-08-09 1:19 ` Ed Falis 2001-08-09 3:15 ` Kaz Kylheku 1 sibling, 1 reply; 875+ messages in thread From: Chris Wolfe @ 2001-08-09 0:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 0:19 ` Chris Wolfe @ 2001-08-09 1:19 ` Ed Falis 0 siblings, 0 replies; 875+ messages in thread From: Ed Falis @ 2001-08-09 1:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 23:44 ` Ed Falis 2001-08-09 0:19 ` Chris Wolfe @ 2001-08-09 3:15 ` Kaz Kylheku 1 sibling, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-09 3:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 23:12 ` Chris Wolfe 2001-08-08 23:44 ` Ed Falis @ 2001-08-09 5:48 ` Warren W. Gay VE3WWG 2001-08-09 14:48 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-09 5:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-08 23:12 ` Chris Wolfe 2001-08-08 23:44 ` Ed Falis 2001-08-09 5:48 ` Warren W. Gay VE3WWG @ 2001-08-09 14:48 ` Ted Dennison 2001-08-09 23:55 ` Martin Ambuhl ` (2 more replies) 2 siblings, 3 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-09 14:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-09 14:48 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison @ 2001-08-09 23:55 ` Martin Ambuhl 2001-08-14 12:25 ` cppwiz 2001-08-14 15:39 ` Stanley R. Allen 2 siblings, 0 replies; 875+ messages in thread From: Martin Ambuhl @ 2001-08-09 23:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-09 14:48 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-09 23:55 ` Martin Ambuhl @ 2001-08-14 12:25 ` cppwiz 2001-08-14 15:39 ` Stanley R. Allen 2 siblings, 0 replies; 875+ messages in thread From: cppwiz @ 2001-08-14 12:25 UTC (permalink / raw) [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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-09 14:48 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-09 23:55 ` Martin Ambuhl 2001-08-14 12:25 ` cppwiz @ 2001-08-14 15:39 ` Stanley R. Allen 2 siblings, 0 replies; 875+ messages in thread From: Stanley R. Allen @ 2001-08-14 15:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:10 ` Warren W. Gay VE3WWG 2001-08-07 1:09 ` Chris Wolfe @ 2001-08-07 7:09 ` Chris Torek 2001-08-08 4:25 ` Warren W. Gay VE3WWG 2001-08-07 12:06 ` Larry Kilgallen ` (3 subsequent siblings) 5 siblings, 1 reply; 875+ messages in thread From: Chris Torek @ 2001-08-07 7:09 UTC (permalink / raw) 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@. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 7:09 ` How Ada could have prevented the Red Code distributed denial of service attack Chris Torek @ 2001-08-08 4:25 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-08 4:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:10 ` Warren W. Gay VE3WWG 2001-08-07 1:09 ` Chris Wolfe 2001-08-07 7:09 ` How Ada could have prevented the Red Code distributed denial of service attack Chris Torek @ 2001-08-07 12:06 ` Larry Kilgallen 2001-08-07 12:42 ` Larry Kilgallen ` (2 subsequent siblings) 5 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-07 12:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 0:10 ` Warren W. Gay VE3WWG ` (2 preceding siblings ...) 2001-08-07 12:06 ` Larry Kilgallen @ 2001-08-07 12:42 ` Larry Kilgallen 2001-08-09 15:25 ` How Ada could have prevented the Red Code distributed denial of Larry Kilgallen [not found] ` <3B6F3FAE.B9B9FOrganization: LJK Software <c78BbJ9nURZD@eisner.encompasserve.org> 5 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-07 12:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-07 0:10 ` Warren W. Gay VE3WWG ` (3 preceding siblings ...) 2001-08-07 12:42 ` Larry Kilgallen @ 2001-08-09 15:25 ` Larry Kilgallen [not found] ` <3B6F3FAE.B9B9FOrganization: LJK Software <c78BbJ9nURZD@eisner.encompasserve.org> 5 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-09 15:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <3B6F3FAE.B9B9FOrganization: LJK Software <c78BbJ9nURZD@eisner.encompasserve.org>]
* Re: How Ada could have prevented the Red Code distributed denial of [not found] ` <3B6F3FAE.B9B9FOrganization: LJK Software <c78BbJ9nURZD@eisner.encompasserve.org> @ 2001-08-09 17:24 ` Ted Dennison 0 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-09 17:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 18:06 ` Preben Randhol 2001-08-03 19:05 ` Dan Cross 2001-08-03 19:37 ` Mark Wilden @ 2001-08-03 19:56 ` Ted Dennison 2001-08-06 15:21 ` Marin David Condic 2 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-03 19:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 19:56 ` How Ada could have prevented the Red Code distributed denial of service attack Ted Dennison @ 2001-08-06 15:21 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-06 15:21 UTC (permalink / raw) 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. :-) > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 15:05 ` Dan Cross 2001-08-03 18:06 ` Preben Randhol @ 2001-08-06 10:04 ` Richard Bos 2001-08-06 14:23 ` Dan Cross 1 sibling, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-06 10:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 10:04 ` Richard Bos @ 2001-08-06 14:23 ` Dan Cross 2001-08-06 14:03 ` Richard Bos 0 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-06 14:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 14:23 ` Dan Cross @ 2001-08-06 14:03 ` Richard Bos 2001-08-06 15:42 ` Dan Cross 0 siblings, 1 reply; 875+ messages in thread From: Richard Bos @ 2001-08-06 14:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 14:03 ` Richard Bos @ 2001-08-06 15:42 ` Dan Cross 0 siblings, 0 replies; 875+ messages in thread From: Dan Cross @ 2001-08-06 15:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 16:10 ` Dan Cross 2001-08-02 16:20 ` Daniel Fischer 2001-08-03 7:26 ` Richard Bos @ 2001-08-06 18:55 ` Bart.Vanhauwaert 2001-08-06 21:54 ` Dan Cross ` (3 more replies) 2 siblings, 4 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-06 18:55 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 18:55 ` Bart.Vanhauwaert @ 2001-08-06 21:54 ` Dan Cross 2001-08-07 11:39 ` Bart.Vanhauwaert 2001-08-06 22:52 ` Ed Falis ` (2 subsequent siblings) 3 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-06 21:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 21:54 ` Dan Cross @ 2001-08-07 11:39 ` Bart.Vanhauwaert 2001-08-07 21:58 ` Dan Cross 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-07 11:39 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 11:39 ` Bart.Vanhauwaert @ 2001-08-07 21:58 ` Dan Cross 2001-08-07 22:51 ` Bart.Vanhauwaert 0 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-07 21:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 21:58 ` Dan Cross @ 2001-08-07 22:51 ` Bart.Vanhauwaert 2001-08-08 14:12 ` Dan Cross 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-07 22:51 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 22:51 ` Bart.Vanhauwaert @ 2001-08-08 14:12 ` Dan Cross 2001-08-08 21:36 ` Bart.Vanhauwaert 0 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-08 14:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 14:12 ` Dan Cross @ 2001-08-08 21:36 ` Bart.Vanhauwaert 2001-08-09 5:54 ` Warren W. Gay VE3WWG ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-08 21:36 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 21:36 ` Bart.Vanhauwaert @ 2001-08-09 5:54 ` Warren W. Gay VE3WWG 2001-08-09 19:34 ` Bart.Vanhauwaert 2001-08-09 15:57 ` How Ada could have prevented the Red Code distributed denial of service attack Marin David Condic 2001-08-12 2:58 ` AG 2 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-09 5:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 5:54 ` Warren W. Gay VE3WWG @ 2001-08-09 19:34 ` Bart.Vanhauwaert 2001-08-09 23:29 ` Mark Wilden 2001-08-10 1:23 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-09 19:34 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:34 ` Bart.Vanhauwaert @ 2001-08-09 23:29 ` Mark Wilden 2001-08-10 0:46 ` Mark Wilden 2001-08-10 12:04 ` Joona I Palaste 2001-08-10 1:23 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 875+ messages in thread From: Mark Wilden @ 2001-08-09 23:29 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 23:29 ` Mark Wilden @ 2001-08-10 0:46 ` Mark Wilden 2001-08-10 12:46 ` Bart.Vanhauwaert 2001-08-10 12:04 ` Joona I Palaste 1 sibling, 1 reply; 875+ messages in thread From: Mark Wilden @ 2001-08-10 0:46 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 0:46 ` Mark Wilden @ 2001-08-10 12:46 ` Bart.Vanhauwaert 2001-08-10 15:53 ` Mark Wilden 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-10 12:46 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 12:46 ` Bart.Vanhauwaert @ 2001-08-10 15:53 ` Mark Wilden 0 siblings, 0 replies; 875+ messages in thread From: Mark Wilden @ 2001-08-10 15:53 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 23:29 ` Mark Wilden 2001-08-10 0:46 ` Mark Wilden @ 2001-08-10 12:04 ` Joona I Palaste 1 sibling, 0 replies; 875+ messages in thread From: Joona I Palaste @ 2001-08-10 12:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:34 ` Bart.Vanhauwaert 2001-08-09 23:29 ` Mark Wilden @ 2001-08-10 1:23 ` Warren W. Gay VE3WWG 2001-08-10 14:33 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 1 sibling, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-10 1:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-10 1:23 ` Warren W. Gay VE3WWG @ 2001-08-10 14:33 ` Ted Dennison 2001-08-10 15:32 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-10 14:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-10 14:33 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison @ 2001-08-10 15:32 ` Warren W. Gay VE3WWG 2001-08-11 3:56 ` David Starner 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-10 15:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-10 15:32 ` Warren W. Gay VE3WWG @ 2001-08-11 3:56 ` David Starner 2001-08-11 14:10 ` Warren W. Gay VE3WWG 2001-08-11 14:27 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 875+ messages in thread From: David Starner @ 2001-08-11 3:56 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-11 3:56 ` David Starner @ 2001-08-11 14:10 ` Warren W. Gay VE3WWG 2001-08-11 14:27 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-11 14:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-11 3:56 ` David Starner 2001-08-11 14:10 ` Warren W. Gay VE3WWG @ 2001-08-11 14:27 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-11 14:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 21:36 ` Bart.Vanhauwaert 2001-08-09 5:54 ` Warren W. Gay VE3WWG @ 2001-08-09 15:57 ` Marin David Condic 2001-08-09 19:42 ` Joachim Durchholz ` (3 more replies) 2001-08-12 2:58 ` AG 2 siblings, 4 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-09 15:57 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 15:57 ` How Ada could have prevented the Red Code distributed denial of service attack Marin David Condic @ 2001-08-09 19:42 ` Joachim Durchholz 2001-08-09 20:05 ` Larry Kilgallen ` (2 more replies) 2001-08-10 5:16 ` Nicholas James NETHERCOTE ` (2 subsequent siblings) 3 siblings, 3 replies; 875+ messages in thread From: Joachim Durchholz @ 2001-08-09 19:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:42 ` Joachim Durchholz @ 2001-08-09 20:05 ` Larry Kilgallen 2001-08-10 6:47 ` Joachim Durchholz 2001-08-10 7:14 ` Ketil Z Malde 2001-08-09 20:09 ` Mark Wilden 2001-08-09 20:16 ` Marin David Condic 2 siblings, 2 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-09 20:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 20:05 ` Larry Kilgallen @ 2001-08-10 6:47 ` Joachim Durchholz 2001-08-10 7:14 ` Ketil Z Malde 1 sibling, 0 replies; 875+ messages in thread From: Joachim Durchholz @ 2001-08-10 6:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 20:05 ` Larry Kilgallen 2001-08-10 6:47 ` Joachim Durchholz @ 2001-08-10 7:14 ` Ketil Z Malde 1 sibling, 0 replies; 875+ messages in thread From: Ketil Z Malde @ 2001-08-10 7:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:42 ` Joachim Durchholz 2001-08-09 20:05 ` Larry Kilgallen @ 2001-08-09 20:09 ` Mark Wilden 2001-08-09 20:16 ` Marin David Condic 2 siblings, 0 replies; 875+ messages in thread From: Mark Wilden @ 2001-08-09 20:09 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 19:42 ` Joachim Durchholz 2001-08-09 20:05 ` Larry Kilgallen 2001-08-09 20:09 ` Mark Wilden @ 2001-08-09 20:16 ` Marin David Condic 2 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-09 20:16 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 15:57 ` How Ada could have prevented the Red Code distributed denial of service attack Marin David Condic 2001-08-09 19:42 ` Joachim Durchholz @ 2001-08-10 5:16 ` Nicholas James NETHERCOTE 2001-08-10 6:37 ` Richard Heathfield 2001-08-10 8:59 ` Andreas Rossberg 3 siblings, 0 replies; 875+ messages in thread From: Nicholas James NETHERCOTE @ 2001-08-10 5:16 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 15:57 ` How Ada could have prevented the Red Code distributed denial of service attack Marin David Condic 2001-08-09 19:42 ` Joachim Durchholz 2001-08-10 5:16 ` Nicholas James NETHERCOTE @ 2001-08-10 6:37 ` Richard Heathfield 2001-08-10 13:40 ` Marin David Condic 2001-08-10 8:59 ` Andreas Rossberg 3 siblings, 1 reply; 875+ messages in thread From: Richard Heathfield @ 2001-08-10 6:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 6:37 ` Richard Heathfield @ 2001-08-10 13:40 ` Marin David Condic 2001-08-10 17:16 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-10 13:40 UTC (permalink / raw) 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.) > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 13:40 ` Marin David Condic @ 2001-08-10 17:16 ` Kaz Kylheku 2001-08-13 9:27 ` Ulf Wiger 0 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-10 17:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-10 17:16 ` Kaz Kylheku @ 2001-08-13 9:27 ` Ulf Wiger 0 siblings, 0 replies; 875+ messages in thread From: Ulf Wiger @ 2001-08-13 9:27 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-09 15:57 ` How Ada could have prevented the Red Code distributed denial of service attack Marin David Condic ` (2 preceding siblings ...) 2001-08-10 6:37 ` Richard Heathfield @ 2001-08-10 8:59 ` Andreas Rossberg 3 siblings, 0 replies; 875+ messages in thread From: Andreas Rossberg @ 2001-08-10 8:59 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-08 21:36 ` Bart.Vanhauwaert 2001-08-09 5:54 ` Warren W. Gay VE3WWG 2001-08-09 15:57 ` How Ada could have prevented the Red Code distributed denial of service attack Marin David Condic @ 2001-08-12 2:58 ` AG 2 siblings, 0 replies; 875+ messages in thread From: AG @ 2001-08-12 2:58 UTC (permalink / raw) <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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 18:55 ` Bart.Vanhauwaert 2001-08-06 21:54 ` Dan Cross @ 2001-08-06 22:52 ` Ed Falis 2001-08-07 13:51 ` Marin David Condic 2001-08-07 19:39 ` Fergus Henderson 3 siblings, 0 replies; 875+ messages in thread From: Ed Falis @ 2001-08-06 22:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 18:55 ` Bart.Vanhauwaert 2001-08-06 21:54 ` Dan Cross 2001-08-06 22:52 ` Ed Falis @ 2001-08-07 13:51 ` Marin David Condic 2001-08-07 22:28 ` Bart.Vanhauwaert 2001-08-07 19:39 ` Fergus Henderson 3 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-07 13:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 13:51 ` Marin David Condic @ 2001-08-07 22:28 ` Bart.Vanhauwaert 2001-08-07 23:06 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Bart.Vanhauwaert @ 2001-08-07 22:28 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 22:28 ` Bart.Vanhauwaert @ 2001-08-07 23:06 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-07 23:06 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-06 18:55 ` Bart.Vanhauwaert ` (2 preceding siblings ...) 2001-08-07 13:51 ` Marin David Condic @ 2001-08-07 19:39 ` Fergus Henderson 3 siblings, 0 replies; 875+ messages in thread From: Fergus Henderson @ 2001-08-07 19:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 18:11 ` Ted Dennison 2001-08-01 18:40 ` Chris Torek 2001-08-01 18:43 ` Ted Dennison @ 2001-08-01 19:08 ` tmoran 2001-08-01 21:41 ` Florian Weimer 2 siblings, 1 reply; 875+ messages in thread From: tmoran @ 2001-08-01 19:08 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 19:08 ` tmoran @ 2001-08-01 21:41 ` Florian Weimer 2001-08-01 23:34 ` tmoran 0 siblings, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-08-01 21:41 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 21:41 ` Florian Weimer @ 2001-08-01 23:34 ` tmoran 2001-08-02 1:29 ` Florian Weimer 0 siblings, 1 reply; 875+ messages in thread From: tmoran @ 2001-08-01 23:34 UTC (permalink / raw) > > 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". ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 23:34 ` tmoran @ 2001-08-02 1:29 ` Florian Weimer 2001-08-02 3:11 ` tmoran 2001-08-02 21:06 ` chris.danx 0 siblings, 2 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-02 1:29 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 1:29 ` Florian Weimer @ 2001-08-02 3:11 ` tmoran 2001-08-03 17:54 ` Dale Pontius 2001-08-05 8:30 ` Florian Weimer 2001-08-02 21:06 ` chris.danx 1 sibling, 2 replies; 875+ messages in thread From: tmoran @ 2001-08-02 3:11 UTC (permalink / raw) > 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 3:11 ` tmoran @ 2001-08-03 17:54 ` Dale Pontius 2001-08-05 8:23 ` Florian Weimer 2001-08-05 8:30 ` Florian Weimer 1 sibling, 1 reply; 875+ messages in thread From: Dale Pontius @ 2001-08-03 17:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 17:54 ` Dale Pontius @ 2001-08-05 8:23 ` Florian Weimer 0 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-05 8:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 3:11 ` tmoran 2001-08-03 17:54 ` Dale Pontius @ 2001-08-05 8:30 ` Florian Weimer 1 sibling, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-05 8:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 1:29 ` Florian Weimer 2001-08-02 3:11 ` tmoran @ 2001-08-02 21:06 ` chris.danx 2001-08-03 10:20 ` chris.danx 2001-08-03 14:00 ` Evil browser-specific web sites (was: " Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: chris.danx @ 2001-08-02 21:06 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 21:06 ` chris.danx @ 2001-08-03 10:20 ` chris.danx 2001-08-03 14:00 ` Evil browser-specific web sites (was: " Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: chris.danx @ 2001-08-03 10:20 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Evil browser-specific web sites (was: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-02 21:06 ` chris.danx 2001-08-03 10:20 ` chris.danx @ 2001-08-03 14:00 ` Ted Dennison 2001-08-03 15:27 ` Larry Kilgallen 2001-08-03 20:51 ` chris.danx 1 sibling, 2 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-03 14:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Evil browser-specific web sites (was: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:00 ` Evil browser-specific web sites (was: " Ted Dennison @ 2001-08-03 15:27 ` Larry Kilgallen 2001-08-03 20:51 ` chris.danx 1 sibling, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-03 15:27 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Evil browser-specific web sites (was: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-03 14:00 ` Evil browser-specific web sites (was: " Ted Dennison 2001-08-03 15:27 ` Larry Kilgallen @ 2001-08-03 20:51 ` chris.danx 1 sibling, 0 replies; 875+ messages in thread From: chris.danx @ 2001-08-03 20:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 17:49 ` Robert Dewar 2001-08-01 18:11 ` Ted Dennison @ 2001-08-01 22:42 ` Hartmann Schaffer 2001-08-02 1:09 ` Florian Weimer 2001-08-04 18:36 ` David Lee Lambert 2 siblings, 1 reply; 875+ messages in thread From: Hartmann Schaffer @ 2001-08-01 22:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 22:42 ` Hartmann Schaffer @ 2001-08-02 1:09 ` Florian Weimer 0 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-02 1:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 17:49 ` Robert Dewar 2001-08-01 18:11 ` Ted Dennison 2001-08-01 22:42 ` Hartmann Schaffer @ 2001-08-04 18:36 ` David Lee Lambert 2001-08-04 21:05 ` David Wagner ` (4 more replies) 2 siblings, 5 replies; 875+ messages in thread From: David Lee Lambert @ 2001-08-04 18:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 18:36 ` David Lee Lambert @ 2001-08-04 21:05 ` David Wagner 2001-08-05 3:00 ` How Ada could have prevented the Red Code distributed denial ofservice attack Warren W. Gay VE3WWG ` (3 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: David Wagner @ 2001-08-04 21:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial ofservice attack. 2001-08-04 18:36 ` David Lee Lambert 2001-08-04 21:05 ` David Wagner @ 2001-08-05 3:00 ` Warren W. Gay VE3WWG 2001-08-05 6:00 ` CBFalconer ` (2 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-05 3:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial ofservice attack. 2001-08-04 18:36 ` David Lee Lambert 2001-08-04 21:05 ` David Wagner 2001-08-05 3:00 ` How Ada could have prevented the Red Code distributed denial ofservice attack Warren W. Gay VE3WWG @ 2001-08-05 6:00 ` CBFalconer 2001-08-06 15:29 ` Marin David Condic 2001-08-05 8:15 ` How Ada could have prevented the Red Code distributed denial of service attack Marcin 'Qrczak' Kowalczyk 2001-08-05 9:36 ` Preben Randhol 4 siblings, 1 reply; 875+ messages in thread From: CBFalconer @ 2001-08-05 6:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial ofservice attack. 2001-08-05 6:00 ` CBFalconer @ 2001-08-06 15:29 ` Marin David Condic 2001-08-07 2:50 ` Mike Silva 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-06 15:29 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial ofservice attack. 2001-08-06 15:29 ` Marin David Condic @ 2001-08-07 2:50 ` Mike Silva 0 siblings, 0 replies; 875+ messages in thread From: Mike Silva @ 2001-08-07 2:50 UTC (permalink / raw) 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. > > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 18:36 ` David Lee Lambert ` (2 preceding siblings ...) 2001-08-05 6:00 ` CBFalconer @ 2001-08-05 8:15 ` Marcin 'Qrczak' Kowalczyk 2001-08-05 9:36 ` Preben Randhol 4 siblings, 0 replies; 875+ messages in thread From: Marcin 'Qrczak' Kowalczyk @ 2001-08-05 8:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-04 18:36 ` David Lee Lambert ` (3 preceding siblings ...) 2001-08-05 8:15 ` How Ada could have prevented the Red Code distributed denial of service attack Marcin 'Qrczak' Kowalczyk @ 2001-08-05 9:36 ` Preben Randhol 4 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-05 9:36 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj ` (3 preceding siblings ...) 2001-08-01 13:09 ` Mike Smith @ 2001-08-07 14:34 ` Attila Feher 2001-08-08 19:16 ` Simon Wright 2001-08-12 7:41 ` How Ada " Will 5 siblings, 1 reply; 875+ messages in thread From: Attila Feher @ 2001-08-07 14:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-07 14:34 ` Attila Feher @ 2001-08-08 19:16 ` Simon Wright 2001-08-12 6:22 ` How a modern programming language " raj 0 siblings, 1 reply; 875+ messages in thread From: Simon Wright @ 2001-08-08 19:16 UTC (permalink / raw) 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 .. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How a modern programming language could have prevented the Red Code distributed denial of service attack. 2001-08-08 19:16 ` Simon Wright @ 2001-08-12 6:22 ` raj 0 siblings, 0 replies; 875+ messages in thread From: raj @ 2001-08-12 6:22 UTC (permalink / raw) > >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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj ` (4 preceding siblings ...) 2001-08-07 14:34 ` Attila Feher @ 2001-08-12 7:41 ` Will 2001-08-12 17:38 ` Joona I Palaste ` (5 more replies) 5 siblings, 6 replies; 875+ messages in thread From: Will @ 2001-08-12 7:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 7:41 ` How Ada " Will @ 2001-08-12 17:38 ` Joona I Palaste 2001-08-12 18:22 ` Rajat Datta 2001-08-12 18:52 ` Dillo 2001-08-12 19:19 ` Gautier ` (4 subsequent siblings) 5 siblings, 2 replies; 875+ messages in thread From: Joona I Palaste @ 2001-08-12 17:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 17:38 ` Joona I Palaste @ 2001-08-12 18:22 ` Rajat Datta 2001-08-12 18:52 ` Dillo 1 sibling, 0 replies; 875+ messages in thread From: Rajat Datta @ 2001-08-12 18:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 17:38 ` Joona I Palaste 2001-08-12 18:22 ` Rajat Datta @ 2001-08-12 18:52 ` Dillo 1 sibling, 0 replies; 875+ messages in thread From: Dillo @ 2001-08-12 18:52 UTC (permalink / raw) 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!! ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 7:41 ` How Ada " Will 2001-08-12 17:38 ` Joona I Palaste @ 2001-08-12 19:19 ` Gautier 2001-08-12 21:57 ` Tore Lund 2001-08-12 20:38 ` Tim Robinson ` (3 subsequent siblings) 5 siblings, 1 reply; 875+ messages in thread From: Gautier @ 2001-08-12 19:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 19:19 ` Gautier @ 2001-08-12 21:57 ` Tore Lund 0 siblings, 0 replies; 875+ messages in thread From: Tore Lund @ 2001-08-12 21:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 7:41 ` How Ada " Will 2001-08-12 17:38 ` Joona I Palaste 2001-08-12 19:19 ` Gautier @ 2001-08-12 20:38 ` Tim Robinson 2001-08-12 22:02 ` tmoran 2001-08-16 1:53 ` Tony Gair 2001-08-13 13:28 ` How Ada could have prevented the Red Code distributed denial of service attack Ted Dennison ` (2 subsequent siblings) 5 siblings, 2 replies; 875+ messages in thread From: Tim Robinson @ 2001-08-12 20:38 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 20:38 ` Tim Robinson @ 2001-08-12 22:02 ` tmoran 2001-08-16 1:53 ` Tony Gair 1 sibling, 0 replies; 875+ messages in thread From: tmoran @ 2001-08-12 22:02 UTC (permalink / raw) | 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 20:38 ` Tim Robinson 2001-08-12 22:02 ` tmoran @ 2001-08-16 1:53 ` Tony Gair 2001-08-16 13:29 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Tony Gair @ 2001-08-16 1:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 1:53 ` Tony Gair @ 2001-08-16 13:29 ` Marin David Condic 2001-08-16 20:52 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-16 13:29 UTC (permalink / raw) 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, > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-16 13:29 ` Marin David Condic @ 2001-08-16 20:52 ` Warren W. Gay VE3WWG 2001-08-16 21:37 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-16 20:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-16 20:52 ` Warren W. Gay VE3WWG @ 2001-08-16 21:37 ` Marin David Condic 2001-08-17 14:25 ` Ted Dennison 2001-08-17 16:36 ` Jeffrey Carter 0 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-16 21:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-16 21:37 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Marin David Condic @ 2001-08-17 14:25 ` Ted Dennison 2001-08-17 16:36 ` Jeffrey Carter 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-17 14:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-16 21:37 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Marin David Condic 2001-08-17 14:25 ` Ted Dennison @ 2001-08-17 16:36 ` Jeffrey Carter 2001-08-17 17:19 ` Marin David Condic ` (4 more replies) 1 sibling, 5 replies; 875+ messages in thread From: Jeffrey Carter @ 2001-08-17 16:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-17 16:36 ` Jeffrey Carter @ 2001-08-17 17:19 ` Marin David Condic 2001-08-17 18:04 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Ted Dennison ` (3 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-17 17:19 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-17 16:36 ` Jeffrey Carter 2001-08-17 17:19 ` Marin David Condic @ 2001-08-17 18:04 ` Ted Dennison 2001-08-17 18:09 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Warren W. Gay VE3WWG ` (2 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-17 18:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-17 16:36 ` Jeffrey Carter 2001-08-17 17:19 ` Marin David Condic 2001-08-17 18:04 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Ted Dennison @ 2001-08-17 18:09 ` Warren W. Gay VE3WWG 2001-08-18 2:56 ` Robert Dewar 2001-08-21 15:52 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Darren New 4 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-17 18:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-17 16:36 ` Jeffrey Carter ` (2 preceding siblings ...) 2001-08-17 18:09 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Warren W. Gay VE3WWG @ 2001-08-18 2:56 ` Robert Dewar 2001-08-18 7:32 ` David Starner 2001-08-19 6:53 ` Jeffrey Carter 2001-08-21 15:52 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Darren New 4 siblings, 2 replies; 875+ messages in thread From: Robert Dewar @ 2001-08-18 2:56 UTC (permalink / raw) 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 :-) :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-18 2:56 ` Robert Dewar @ 2001-08-18 7:32 ` David Starner 2001-08-19 6:53 ` Jeffrey Carter 1 sibling, 0 replies; 875+ messages in thread From: David Starner @ 2001-08-18 7:32 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-18 2:56 ` Robert Dewar 2001-08-18 7:32 ` David Starner @ 2001-08-19 6:53 ` Jeffrey Carter 2001-08-19 17:00 ` Florian Weimer 2001-08-20 14:00 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Ted Dennison 1 sibling, 2 replies; 875+ messages in thread From: Jeffrey Carter @ 2001-08-19 6:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-19 6:53 ` Jeffrey Carter @ 2001-08-19 17:00 ` Florian Weimer 2001-08-20 14:00 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-19 17:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-19 6:53 ` Jeffrey Carter 2001-08-19 17:00 ` Florian Weimer @ 2001-08-20 14:00 ` Ted Dennison 2001-08-20 14:24 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-20 14:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-20 14:00 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Ted Dennison @ 2001-08-20 14:24 ` Marin David Condic 2001-08-20 23:24 ` Didier Utheza 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-20 14:24 UTC (permalink / raw) 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. > > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-20 14:24 ` Marin David Condic @ 2001-08-20 23:24 ` Didier Utheza 2001-08-21 13:43 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Didier Utheza @ 2001-08-20 23:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-20 23:24 ` Didier Utheza @ 2001-08-21 13:43 ` Marin David Condic 2001-08-21 15:05 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-21 13:43 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 13:43 ` Marin David Condic @ 2001-08-21 15:05 ` Warren W. Gay VE3WWG 2001-08-21 15:29 ` Marin David Condic 2001-08-21 20:50 ` David Starner 0 siblings, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-21 15:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 15:05 ` Warren W. Gay VE3WWG @ 2001-08-21 15:29 ` Marin David Condic 2001-08-21 17:03 ` Warren W. Gay VE3WWG 2001-08-21 21:21 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red David Starner 2001-08-21 20:50 ` David Starner 1 sibling, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-21 15:29 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 15:29 ` Marin David Condic @ 2001-08-21 17:03 ` Warren W. Gay VE3WWG 2001-08-21 22:03 ` Didier Utheza ` (9 more replies) 2001-08-21 21:21 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red David Starner 1 sibling, 10 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-21 17:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 17:03 ` Warren W. Gay VE3WWG @ 2001-08-21 22:03 ` Didier Utheza 2001-08-22 13:44 ` Marin David Condic 2001-08-22 18:32 ` Progress on AdaOS Larry Kilgallen ` (8 subsequent siblings) 9 siblings, 1 reply; 875+ messages in thread From: Didier Utheza @ 2001-08-21 22:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 22:03 ` Didier Utheza @ 2001-08-22 13:44 ` Marin David Condic 2001-08-22 16:30 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-22 13:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 13:44 ` Marin David Condic @ 2001-08-22 16:30 ` Warren W. Gay VE3WWG 2001-08-22 17:03 ` Progress on AdaOS Marin David Condic 2001-08-22 17:17 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Preben Randhol 0 siblings, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-22 16:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-22 16:30 ` Warren W. Gay VE3WWG @ 2001-08-22 17:03 ` Marin David Condic 2001-08-22 18:21 ` Ted Dennison 2001-08-22 18:23 ` Warren W. Gay VE3WWG 2001-08-22 17:17 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Preben Randhol 1 sibling, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-22 17:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-22 17:03 ` Progress on AdaOS Marin David Condic @ 2001-08-22 18:21 ` Ted Dennison 2001-08-22 19:50 ` Marin David Condic 2001-08-22 18:23 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-22 18:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-22 18:21 ` Ted Dennison @ 2001-08-22 19:50 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-22 19:50 UTC (permalink / raw) 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. :-) > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-22 17:03 ` Progress on AdaOS Marin David Condic 2001-08-22 18:21 ` Ted Dennison @ 2001-08-22 18:23 ` Warren W. Gay VE3WWG 2001-08-22 19:54 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-22 18:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-22 18:23 ` Warren W. Gay VE3WWG @ 2001-08-22 19:54 ` Marin David Condic 2001-08-23 3:42 ` David Starner 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-22 19:54 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-22 19:54 ` Marin David Condic @ 2001-08-23 3:42 ` David Starner 2001-08-23 17:17 ` Open Source Approach (was Progress on AdaOS) Warren W. Gay VE3WWG 2001-08-23 18:36 ` Progress on AdaOS Marin David Condic 0 siblings, 2 replies; 875+ messages in thread From: David Starner @ 2001-08-23 3:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Open Source Approach (was Progress on AdaOS) 2001-08-23 3:42 ` David Starner @ 2001-08-23 17:17 ` Warren W. Gay VE3WWG 2001-08-24 1:04 ` Gerhard Häring 2001-08-23 18:36 ` Progress on AdaOS Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-23 17:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Open Source Approach (was Progress on AdaOS) 2001-08-23 17:17 ` Open Source Approach (was Progress on AdaOS) Warren W. Gay VE3WWG @ 2001-08-24 1:04 ` Gerhard Häring 2001-08-24 15:27 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Gerhard Häring @ 2001-08-24 1:04 UTC (permalink / raw) 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'))) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Open Source Approach (was Progress on AdaOS) 2001-08-24 1:04 ` Gerhard Häring @ 2001-08-24 15:27 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-24 15:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-23 3:42 ` David Starner 2001-08-23 17:17 ` Open Source Approach (was Progress on AdaOS) Warren W. Gay VE3WWG @ 2001-08-23 18:36 ` Marin David Condic 2001-08-24 1:03 ` David Starner 1 sibling, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-23 18:36 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-23 18:36 ` Progress on AdaOS Marin David Condic @ 2001-08-24 1:03 ` David Starner 2001-08-24 13:47 ` Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-24 1:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-24 1:03 ` David Starner @ 2001-08-24 13:47 ` Ted Dennison 2001-08-24 14:42 ` Marin David Condic 2001-08-24 16:25 ` Gary Scott 0 siblings, 2 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-24 13:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-24 13:47 ` Ted Dennison @ 2001-08-24 14:42 ` Marin David Condic 2001-08-24 16:25 ` Gary Scott 1 sibling, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-24 14:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-24 13:47 ` Ted Dennison 2001-08-24 14:42 ` Marin David Condic @ 2001-08-24 16:25 ` Gary Scott 2001-08-24 16:53 ` O/S Research is Dead? (was Progress on AdaOS) Warren W. Gay VE3WWG 2001-08-24 22:01 ` Progress on AdaOS David Starner 1 sibling, 2 replies; 875+ messages in thread From: Gary Scott @ 2001-08-24 16:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* O/S Research is Dead? (was Progress on AdaOS) 2001-08-24 16:25 ` Gary Scott @ 2001-08-24 16:53 ` Warren W. Gay VE3WWG 2001-08-24 22:01 ` Progress on AdaOS David Starner 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-24 16:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-24 16:25 ` Gary Scott 2001-08-24 16:53 ` O/S Research is Dead? (was Progress on AdaOS) Warren W. Gay VE3WWG @ 2001-08-24 22:01 ` David Starner 2001-08-25 17:19 ` Gary Scott 1 sibling, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-24 22:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-24 22:01 ` Progress on AdaOS David Starner @ 2001-08-25 17:19 ` Gary Scott 2001-08-26 7:51 ` David Starner 0 siblings, 1 reply; 875+ messages in thread From: Gary Scott @ 2001-08-25 17:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-25 17:19 ` Gary Scott @ 2001-08-26 7:51 ` David Starner 0 siblings, 0 replies; 875+ messages in thread From: David Starner @ 2001-08-26 7:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 16:30 ` Warren W. Gay VE3WWG 2001-08-22 17:03 ` Progress on AdaOS Marin David Condic @ 2001-08-22 17:17 ` Preben Randhol 2001-08-22 17:45 ` Didier Utheza 1 sibling, 1 reply; 875+ messages in thread From: Preben Randhol @ 2001-08-22 17:17 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 17:17 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Preben Randhol @ 2001-08-22 17:45 ` Didier Utheza 2001-08-22 19:08 ` Preben Randhol 0 siblings, 1 reply; 875+ messages in thread From: Didier Utheza @ 2001-08-22 17:45 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 17:45 ` Didier Utheza @ 2001-08-22 19:08 ` Preben Randhol 0 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-22 19:08 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-21 17:03 ` Warren W. Gay VE3WWG 2001-08-21 22:03 ` Didier Utheza @ 2001-08-22 18:32 ` Larry Kilgallen [not found] ` <Pine.A41.4.10.Organization: LJK Software <Ypd7dD0WS5sw@eisner.encompasserve.org> ` (7 subsequent siblings) 9 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-22 18:32 UTC (permalink / raw) 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 :-). ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <Pine.A41.4.10.Organization: LJK Software <Ypd7dD0WS5sw@eisner.encompasserve.org>]
* Re: Progress on AdaOS [not found] ` <Pine.A41.4.10.Organization: LJK Software <Ypd7dD0WS5sw@eisner.encompasserve.org> @ 2001-08-22 20:00 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-22 20:00 UTC (permalink / raw) 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 :-). ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-21 17:03 ` Warren W. Gay VE3WWG ` (2 preceding siblings ...) [not found] ` <Pine.A41.4.10.Organization: LJK Software <Ypd7dD0WS5sw@eisner.encompasserve.org> @ 2001-08-24 20:34 ` Larry Kilgallen 2001-08-25 1:31 ` Larry Kilgallen ` (5 subsequent siblings) 9 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-24 20:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-21 17:03 ` Warren W. Gay VE3WWG ` (3 preceding siblings ...) 2001-08-24 20:34 ` Larry Kilgallen @ 2001-08-25 1:31 ` Larry Kilgallen 2001-08-25 17:11 ` David Starner 2001-08-26 11:47 ` Larry Kilgallen ` (4 subsequent siblings) 9 siblings, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-08-25 1:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-25 1:31 ` Larry Kilgallen @ 2001-08-25 17:11 ` David Starner 2001-08-25 19:34 ` Gary Scott 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-25 17:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-25 17:11 ` David Starner @ 2001-08-25 19:34 ` Gary Scott 2001-08-25 20:00 ` Gary Scott 2001-08-26 7:59 ` David Starner 0 siblings, 2 replies; 875+ messages in thread From: Gary Scott @ 2001-08-25 19:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-25 19:34 ` Gary Scott @ 2001-08-25 20:00 ` Gary Scott 2001-08-26 7:59 ` David Starner 1 sibling, 0 replies; 875+ messages in thread From: Gary Scott @ 2001-08-25 20:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-25 19:34 ` Gary Scott 2001-08-25 20:00 ` Gary Scott @ 2001-08-26 7:59 ` David Starner 1 sibling, 0 replies; 875+ messages in thread From: David Starner @ 2001-08-26 7:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-21 17:03 ` Warren W. Gay VE3WWG ` (4 preceding siblings ...) 2001-08-25 1:31 ` Larry Kilgallen @ 2001-08-26 11:47 ` Larry Kilgallen 2001-08-26 16:31 ` David Starner [not found] ` <Pine.A41.4.10.Organization: LJK Software <uBW9YP9YCoMO@eisner.encompasserve.org> ` (3 subsequent siblings) 9 siblings, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-08-26 11:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-26 11:47 ` Larry Kilgallen @ 2001-08-26 16:31 ` David Starner 2001-08-27 7:46 ` Frédéric Valdes 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-26 16:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-26 16:31 ` David Starner @ 2001-08-27 7:46 ` Frédéric Valdes 0 siblings, 0 replies; 875+ messages in thread From: Frédéric Valdes @ 2001-08-27 7:46 UTC (permalink / raw) 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 -+- ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <Pine.A41.4.10.Organization: LJK Software <uBW9YP9YCoMO@eisner.encompasserve.org>]
* Re: Progress on AdaOS [not found] ` <Pine.A41.4.10.Organization: LJK Software <uBW9YP9YCoMO@eisner.encompasserve.org> @ 2001-08-27 13:14 ` Marin David Condic 2001-08-27 17:30 ` David Starner 2001-08-28 11:07 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-27 13:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-27 13:14 ` Marin David Condic @ 2001-08-27 17:30 ` David Starner 2001-08-27 21:08 ` Darren New 2001-08-28 11:07 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-27 17:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-27 17:30 ` David Starner @ 2001-08-27 21:08 ` Darren New 2001-08-28 1:51 ` David Starner 2001-08-29 15:56 ` Samuel T. Harris 0 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-08-27 21:08 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-27 21:08 ` Darren New @ 2001-08-28 1:51 ` David Starner 2001-08-28 16:13 ` Darren New 2001-08-29 15:56 ` Samuel T. Harris 1 sibling, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-28 1:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-28 1:51 ` David Starner @ 2001-08-28 16:13 ` Darren New 2001-08-29 3:13 ` David Starner 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-08-28 16:13 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-28 16:13 ` Darren New @ 2001-08-29 3:13 ` David Starner 2001-08-29 16:42 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-29 3:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-29 3:13 ` David Starner @ 2001-08-29 16:42 ` Darren New 2001-08-30 6:23 ` David Starner 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-08-29 16:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-29 16:42 ` Darren New @ 2001-08-30 6:23 ` David Starner 2001-08-30 16:37 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-30 6:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-30 6:23 ` David Starner @ 2001-08-30 16:37 ` Darren New 2001-08-31 16:09 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-08-30 16:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-30 16:37 ` Darren New @ 2001-08-31 16:09 ` Darren New 2001-08-31 18:42 ` M. A. Alves 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-08-31 16:09 UTC (permalink / raw) > > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 16:09 ` Darren New @ 2001-08-31 18:42 ` M. A. Alves 2001-08-31 17:58 ` Darren New ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: M. A. Alves @ 2001-08-31 18:42 UTC (permalink / raw) To: comp.lang.ada > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 18:42 ` M. A. Alves @ 2001-08-31 17:58 ` Darren New 2001-08-31 19:31 ` M. A. Alves 2001-09-01 19:21 ` Progress on AdaOS Dmitry A. Kazakov 2001-08-31 23:51 ` Brian Catlin 2001-09-01 23:46 ` Keith Thompson 2 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-08-31 17:58 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 17:58 ` Darren New @ 2001-08-31 19:31 ` M. A. Alves 2001-08-31 19:54 ` Ted Dennison 2001-08-31 20:00 ` Darren New 2001-09-01 19:21 ` Progress on AdaOS Dmitry A. Kazakov 1 sibling, 2 replies; 875+ messages in thread From: M. A. Alves @ 2001-08-31 19:31 UTC (permalink / raw) To: comp.lang.ada > > > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 19:31 ` M. A. Alves @ 2001-08-31 19:54 ` Ted Dennison 2001-08-31 20:00 ` Darren New 1 sibling, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-31 19:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 19:31 ` M. A. Alves 2001-08-31 19:54 ` Ted Dennison @ 2001-08-31 20:00 ` Darren New 2001-09-01 2:31 ` David Starner 1 sibling, 1 reply; 875+ messages in thread From: Darren New @ 2001-08-31 20:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 20:00 ` Darren New @ 2001-09-01 2:31 ` David Starner 2001-09-02 23:02 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-09-01 2:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-01 2:31 ` David Starner @ 2001-09-02 23:02 ` Darren New 2001-09-03 18:36 ` Ada OS talk (was: Progress on AdaOS) M. A. Alves 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-09-02 23:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Ada OS talk (was: Progress on AdaOS) 2001-09-02 23:02 ` Darren New @ 2001-09-03 18:36 ` M. A. Alves 2001-09-03 18:11 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: M. A. Alves @ 2001-09-03 18:36 UTC (permalink / raw) To: comp.lang.ada > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-03 18:36 ` Ada OS talk (was: Progress on AdaOS) M. A. Alves @ 2001-09-03 18:11 ` Darren New 2001-09-03 20:12 ` M. A. Alves 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-09-03 18:11 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-03 18:11 ` Darren New @ 2001-09-03 20:12 ` M. A. Alves 2001-09-04 13:02 ` Marin David Condic 2001-09-04 17:09 ` Darren New 0 siblings, 2 replies; 875+ messages in thread From: M. A. Alves @ 2001-09-03 20:12 UTC (permalink / raw) To: comp.lang.ada > > > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-03 20:12 ` M. A. Alves @ 2001-09-04 13:02 ` Marin David Condic 2001-09-04 14:34 ` Gary Scott ` (2 more replies) 2001-09-04 17:09 ` Darren New 1 sibling, 3 replies; 875+ messages in thread From: Marin David Condic @ 2001-09-04 13:02 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 13:02 ` Marin David Condic @ 2001-09-04 14:34 ` Gary Scott 2001-09-04 19:44 ` Marin David Condic 2001-09-04 17:13 ` Darren New 2001-09-04 21:28 ` David Starner 2 siblings, 1 reply; 875+ messages in thread From: Gary Scott @ 2001-09-04 14:34 UTC (permalink / raw) 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. > > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 14:34 ` Gary Scott @ 2001-09-04 19:44 ` Marin David Condic 2001-09-04 21:00 ` Gary Scott 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-09-04 19:44 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 19:44 ` Marin David Condic @ 2001-09-04 21:00 ` Gary Scott 2001-09-06 13:52 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Gary Scott @ 2001-09-04 21:00 UTC (permalink / raw) 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. > > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 21:00 ` Gary Scott @ 2001-09-06 13:52 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-09-06 13:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 13:02 ` Marin David Condic 2001-09-04 14:34 ` Gary Scott @ 2001-09-04 17:13 ` Darren New 2001-09-04 18:34 ` Marin David Condic 2001-09-05 7:14 ` Ole-Hjalmar Kristensen 2001-09-04 21:28 ` David Starner 2 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-09-04 17:13 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 17:13 ` Darren New @ 2001-09-04 18:34 ` Marin David Condic 2001-09-05 7:14 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-09-04 18:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 17:13 ` Darren New 2001-09-04 18:34 ` Marin David Condic @ 2001-09-05 7:14 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 875+ messages in thread From: Ole-Hjalmar Kristensen @ 2001-09-05 7:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 13:02 ` Marin David Condic 2001-09-04 14:34 ` Gary Scott 2001-09-04 17:13 ` Darren New @ 2001-09-04 21:28 ` David Starner 2001-09-05 5:06 ` Brian Catlin 2001-09-06 13:59 ` Marin David Condic 2 siblings, 2 replies; 875+ messages in thread From: David Starner @ 2001-09-04 21:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 21:28 ` David Starner @ 2001-09-05 5:06 ` Brian Catlin 2001-09-06 13:59 ` Marin David Condic 1 sibling, 0 replies; 875+ messages in thread From: Brian Catlin @ 2001-09-05 5:06 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-04 21:28 ` David Starner 2001-09-05 5:06 ` Brian Catlin @ 2001-09-06 13:59 ` Marin David Condic 2001-09-06 21:00 ` David Starner 1 sibling, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-09-06 13:59 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-06 13:59 ` Marin David Condic @ 2001-09-06 21:00 ` David Starner 2001-09-07 14:24 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-09-06 21:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-06 21:00 ` David Starner @ 2001-09-07 14:24 ` Marin David Condic 2001-09-10 3:20 ` Michael Garrett 2001-09-10 3:55 ` David Starner 0 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-09-07 14:24 UTC (permalink / raw) 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? > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-07 14:24 ` Marin David Condic @ 2001-09-10 3:20 ` Michael Garrett 2001-09-10 12:37 ` RTEMS and Ada, Was: " Simon Clubley 2001-09-10 13:57 ` Marin David Condic 2001-09-10 3:55 ` David Starner 1 sibling, 2 replies; 875+ messages in thread From: Michael Garrett @ 2001-09-10 3:20 UTC (permalink / raw) 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? > > > > > ^ permalink raw reply [flat|nested] 875+ messages in thread
* RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS) 2001-09-10 3:20 ` Michael Garrett @ 2001-09-10 12:37 ` Simon Clubley 2001-09-10 19:29 ` Stephen Leake 2001-09-10 20:56 ` Joel Sherrill 2001-09-10 13:57 ` Marin David Condic 1 sibling, 2 replies; 875+ messages in thread From: Simon Clubley @ 2001-09-10 12:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS) 2001-09-10 12:37 ` RTEMS and Ada, Was: " Simon Clubley @ 2001-09-10 19:29 ` Stephen Leake 2001-09-10 20:25 ` Simon Clubley 2001-09-10 20:56 ` Joel Sherrill 1 sibling, 1 reply; 875+ messages in thread From: Stephen Leake @ 2001-09-10 19:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS) 2001-09-10 19:29 ` Stephen Leake @ 2001-09-10 20:25 ` Simon Clubley 0 siblings, 0 replies; 875+ messages in thread From: Simon Clubley @ 2001-09-10 20:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS) 2001-09-10 12:37 ` RTEMS and Ada, Was: " Simon Clubley 2001-09-10 19:29 ` Stephen Leake @ 2001-09-10 20:56 ` Joel Sherrill 1 sibling, 0 replies; 875+ messages in thread From: Joel Sherrill @ 2001-09-10 20:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-10 3:20 ` Michael Garrett 2001-09-10 12:37 ` RTEMS and Ada, Was: " Simon Clubley @ 2001-09-10 13:57 ` Marin David Condic 2001-09-10 20:39 ` Joel Sherrill 1 sibling, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-09-10 13:57 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-10 13:57 ` Marin David Condic @ 2001-09-10 20:39 ` Joel Sherrill 2001-09-11 4:04 ` Michael Garrett 0 siblings, 1 reply; 875+ messages in thread From: Joel Sherrill @ 2001-09-10 20:39 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-10 20:39 ` Joel Sherrill @ 2001-09-11 4:04 ` Michael Garrett 0 siblings, 0 replies; 875+ messages in thread From: Michael Garrett @ 2001-09-11 4:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-07 14:24 ` Marin David Condic 2001-09-10 3:20 ` Michael Garrett @ 2001-09-10 3:55 ` David Starner 1 sibling, 0 replies; 875+ messages in thread From: David Starner @ 2001-09-10 3:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Ada OS talk (was: Progress on AdaOS) 2001-09-03 20:12 ` M. A. Alves 2001-09-04 13:02 ` Marin David Condic @ 2001-09-04 17:09 ` Darren New 1 sibling, 0 replies; 875+ messages in thread From: Darren New @ 2001-09-04 17:09 UTC (permalink / raw) > > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 17:58 ` Darren New 2001-08-31 19:31 ` M. A. Alves @ 2001-09-01 19:21 ` Dmitry A. Kazakov 2001-09-02 1:09 ` Chad R. Meiners ` (2 more replies) 1 sibling, 3 replies; 875+ messages in thread From: Dmitry A. Kazakov @ 2001-09-01 19:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-01 19:21 ` Progress on AdaOS Dmitry A. Kazakov @ 2001-09-02 1:09 ` Chad R. Meiners 2001-09-02 10:49 ` Dmitry A. Kazakov 2001-09-03 6:39 ` Jean-Pierre Rosen 2001-09-03 19:16 ` M. A. Alves 2 siblings, 1 reply; 875+ messages in thread From: Chad R. Meiners @ 2001-09-02 1:09 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-02 1:09 ` Chad R. Meiners @ 2001-09-02 10:49 ` Dmitry A. Kazakov 0 siblings, 0 replies; 875+ messages in thread From: Dmitry A. Kazakov @ 2001-09-02 10:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-01 19:21 ` Progress on AdaOS Dmitry A. Kazakov 2001-09-02 1:09 ` Chad R. Meiners @ 2001-09-03 6:39 ` Jean-Pierre Rosen 2001-09-05 7:28 ` Dmitry Kazakov 2001-09-03 19:16 ` M. A. Alves 2 siblings, 1 reply; 875+ messages in thread From: Jean-Pierre Rosen @ 2001-09-03 6:39 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-03 6:39 ` Jean-Pierre Rosen @ 2001-09-05 7:28 ` Dmitry Kazakov 0 siblings, 0 replies; 875+ messages in thread From: Dmitry Kazakov @ 2001-09-05 7:28 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-01 19:21 ` Progress on AdaOS Dmitry A. Kazakov 2001-09-02 1:09 ` Chad R. Meiners 2001-09-03 6:39 ` Jean-Pierre Rosen @ 2001-09-03 19:16 ` M. A. Alves 2001-09-05 7:47 ` Dmitry Kazakov 2 siblings, 1 reply; 875+ messages in thread From: M. A. Alves @ 2001-09-03 19:16 UTC (permalink / raw) To: comp.lang.ada > >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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-03 19:16 ` M. A. Alves @ 2001-09-05 7:47 ` Dmitry Kazakov 2001-09-05 16:37 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: Dmitry Kazakov @ 2001-09-05 7:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-05 7:47 ` Dmitry Kazakov @ 2001-09-05 16:37 ` Darren New 2001-09-06 12:33 ` Dmitry A. Kazakov 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-09-05 16:37 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-05 16:37 ` Darren New @ 2001-09-06 12:33 ` Dmitry A. Kazakov 2001-09-06 16:35 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: Dmitry A. Kazakov @ 2001-09-06 12:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-06 12:33 ` Dmitry A. Kazakov @ 2001-09-06 16:35 ` Darren New 2001-09-07 7:49 ` Dmitry Kazakov 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-09-06 16:35 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-06 16:35 ` Darren New @ 2001-09-07 7:49 ` Dmitry Kazakov 2001-09-07 15:58 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: Dmitry Kazakov @ 2001-09-07 7:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-07 7:49 ` Dmitry Kazakov @ 2001-09-07 15:58 ` Darren New 2001-09-08 12:02 ` Dmitry A. Kazakov 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-09-07 15:58 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-07 15:58 ` Darren New @ 2001-09-08 12:02 ` Dmitry A. Kazakov 2001-09-09 2:06 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: Dmitry A. Kazakov @ 2001-09-08 12:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-08 12:02 ` Dmitry A. Kazakov @ 2001-09-09 2:06 ` Darren New 2001-09-09 7:46 ` Larry Kilgallen 2001-09-09 18:35 ` Dmitry A. Kazakov 0 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-09-09 2:06 UTC (permalink / raw) > >> 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-09 2:06 ` Darren New @ 2001-09-09 7:46 ` Larry Kilgallen 2001-09-09 18:35 ` Dmitry A. Kazakov 1 sibling, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-09-09 7:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-09 2:06 ` Darren New 2001-09-09 7:46 ` Larry Kilgallen @ 2001-09-09 18:35 ` Dmitry A. Kazakov 2001-09-09 20:35 ` Darren New 1 sibling, 1 reply; 875+ messages in thread From: Dmitry A. Kazakov @ 2001-09-09 18:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-09 18:35 ` Dmitry A. Kazakov @ 2001-09-09 20:35 ` Darren New 2001-09-10 17:24 ` Dmitry A. Kazakov 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-09-09 20:35 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-09 20:35 ` Darren New @ 2001-09-10 17:24 ` Dmitry A. Kazakov 2001-09-10 18:16 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: Dmitry A. Kazakov @ 2001-09-10 17:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-10 17:24 ` Dmitry A. Kazakov @ 2001-09-10 18:16 ` Darren New 0 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-09-10 18:16 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 18:42 ` M. A. Alves 2001-08-31 17:58 ` Darren New @ 2001-08-31 23:51 ` Brian Catlin 2001-09-01 23:46 ` Keith Thompson 2 siblings, 0 replies; 875+ messages in thread From: Brian Catlin @ 2001-08-31 23:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-31 18:42 ` M. A. Alves 2001-08-31 17:58 ` Darren New 2001-08-31 23:51 ` Brian Catlin @ 2001-09-01 23:46 ` Keith Thompson 2001-09-03 18:54 ` M. A. Alves 2001-09-09 0:43 ` David Thompson 2 siblings, 2 replies; 875+ messages in thread From: Keith Thompson @ 2001-09-01 23:46 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-01 23:46 ` Keith Thompson @ 2001-09-03 18:54 ` M. A. Alves 2001-09-09 0:43 ` David Thompson 1 sibling, 0 replies; 875+ messages in thread From: M. A. Alves @ 2001-09-03 18:54 UTC (permalink / raw) To: comp.lang.ada > > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-01 23:46 ` Keith Thompson 2001-09-03 18:54 ` M. A. Alves @ 2001-09-09 0:43 ` David Thompson 2001-09-10 10:53 ` M. A. Alves 1 sibling, 1 reply; 875+ messages in thread From: David Thompson @ 2001-09-09 0:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-09 0:43 ` David Thompson @ 2001-09-10 10:53 ` M. A. Alves 2001-09-10 18:11 ` David Starner 0 siblings, 1 reply; 875+ messages in thread From: M. A. Alves @ 2001-09-10 10:53 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-10 10:53 ` M. A. Alves @ 2001-09-10 18:11 ` David Starner 2001-09-11 10:45 ` M. A. Alves 0 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-09-10 18:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-09-10 18:11 ` David Starner @ 2001-09-11 10:45 ` M. A. Alves 0 siblings, 0 replies; 875+ messages in thread From: M. A. Alves @ 2001-09-11 10:45 UTC (permalink / raw) To: comp.lang.ada > >> > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-27 21:08 ` Darren New 2001-08-28 1:51 ` David Starner @ 2001-08-29 15:56 ` Samuel T. Harris 1 sibling, 0 replies; 875+ messages in thread From: Samuel T. Harris @ 2001-08-29 15:56 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-27 13:14 ` Marin David Condic 2001-08-27 17:30 ` David Starner @ 2001-08-28 11:07 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 875+ messages in thread From: Ole-Hjalmar Kristensen @ 2001-08-28 11:07 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <Pine.A41.4.10.Organization: LJK Software <QzMRgPYPkyBy@eisner.encompasserve.org>]
* Re: Progress on AdaOS [not found] ` <Pine.A41.4.10.Organization: LJK Software <QzMRgPYPkyBy@eisner.encompasserve.org> @ 2001-08-27 13:27 ` Marin David Condic 2001-08-27 23:21 ` Samuel Tardieu 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-27 13:27 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-27 13:27 ` Marin David Condic @ 2001-08-27 23:21 ` Samuel Tardieu 2001-08-28 13:22 ` Marin David Condic 0 siblings, 1 reply; 875+ messages in thread From: Samuel Tardieu @ 2001-08-27 23:21 UTC (permalink / raw) To: "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> "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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-27 23:21 ` Samuel Tardieu @ 2001-08-28 13:22 ` Marin David Condic 2001-08-29 8:19 ` Samuel Tardieu 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-28 13:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-28 13:22 ` Marin David Condic @ 2001-08-29 8:19 ` Samuel Tardieu 2001-08-29 14:50 ` Tony Gair 2001-09-09 20:34 ` Richard Riehle 0 siblings, 2 replies; 875+ messages in thread From: Samuel Tardieu @ 2001-08-29 8:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-29 8:19 ` Samuel Tardieu @ 2001-08-29 14:50 ` Tony Gair 2001-08-29 15:31 ` Samuel Tardieu 2001-09-09 20:34 ` Richard Riehle 1 sibling, 1 reply; 875+ messages in thread From: Tony Gair @ 2001-08-29 14:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-29 14:50 ` Tony Gair @ 2001-08-29 15:31 ` Samuel Tardieu 0 siblings, 0 replies; 875+ messages in thread From: Samuel Tardieu @ 2001-08-29 15:31 UTC (permalink / raw) To: comp.lang.ada On 29/08, Tony Gair wrote: | you're doing it wrong you should love when its big. When it's too big, it hurts. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-29 8:19 ` Samuel Tardieu 2001-08-29 14:50 ` Tony Gair @ 2001-09-09 20:34 ` Richard Riehle 1 sibling, 0 replies; 875+ messages in thread From: Richard Riehle @ 2001-09-09 20:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS 2001-08-21 17:03 ` Warren W. Gay VE3WWG ` (7 preceding siblings ...) [not found] ` <Pine.A41.4.10.Organization: LJK Software <QzMRgPYPkyBy@eisner.encompasserve.org> @ 2001-08-27 23:30 ` Larry Kilgallen [not found] ` <uBW9YP9YCoMO@eOrganization: LJK Software <sy8cXTZt45T9@eisner.encompasserve.org> 9 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-27 23:30 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <uBW9YP9YCoMO@eOrganization: LJK Software <sy8cXTZt45T9@eisner.encompasserve.org>]
* Re: Progress on AdaOS [not found] ` <uBW9YP9YCoMO@eOrganization: LJK Software <sy8cXTZt45T9@eisner.encompasserve.org> @ 2001-08-28 15:48 ` Steffen Huber 0 siblings, 0 replies; 875+ messages in thread From: Steffen Huber @ 2001-08-28 15:48 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 15:29 ` Marin David Condic 2001-08-21 17:03 ` Warren W. Gay VE3WWG @ 2001-08-21 21:21 ` David Starner 2001-08-22 14:03 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-21 21:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 21:21 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red David Starner @ 2001-08-22 14:03 ` Marin David Condic 2001-08-22 16:42 ` Ted Dennison 2001-08-22 22:15 ` David Starner 0 siblings, 2 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-22 14:03 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 14:03 ` Marin David Condic @ 2001-08-22 16:42 ` Ted Dennison 2001-08-22 17:22 ` Preben Randhol ` (2 more replies) 2001-08-22 22:15 ` David Starner 1 sibling, 3 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-22 16:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 16:42 ` Ted Dennison @ 2001-08-22 17:22 ` Preben Randhol 2001-08-22 21:09 ` Marin David Condic 2001-08-23 8:50 ` Steinar Knutsen 2 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-22 17:22 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 16:42 ` Ted Dennison 2001-08-22 17:22 ` Preben Randhol @ 2001-08-22 21:09 ` Marin David Condic 2001-08-23 8:50 ` Steinar Knutsen 2 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-22 21:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 16:42 ` Ted Dennison 2001-08-22 17:22 ` Preben Randhol 2001-08-22 21:09 ` Marin David Condic @ 2001-08-23 8:50 ` Steinar Knutsen 2 siblings, 0 replies; 875+ messages in thread From: Steinar Knutsen @ 2001-08-23 8:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 14:03 ` Marin David Condic 2001-08-22 16:42 ` Ted Dennison @ 2001-08-22 22:15 ` David Starner 2001-08-23 17:29 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-22 22:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-22 22:15 ` David Starner @ 2001-08-23 17:29 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-23 17:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 15:05 ` Warren W. Gay VE3WWG 2001-08-21 15:29 ` Marin David Condic @ 2001-08-21 20:50 ` David Starner 2001-08-22 1:50 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-21 20:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red 2001-08-21 20:50 ` David Starner @ 2001-08-22 1:50 ` Warren W. Gay VE3WWG 2001-08-22 13:50 ` OT: Progress on AdaOS David Starner 0 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-22 1:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: OT: Progress on AdaOS 2001-08-22 1:50 ` Warren W. Gay VE3WWG @ 2001-08-22 13:50 ` David Starner 0 siblings, 0 replies; 875+ messages in thread From: David Starner @ 2001-08-22 13:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-17 16:36 ` Jeffrey Carter ` (3 preceding siblings ...) 2001-08-18 2:56 ` Robert Dewar @ 2001-08-21 15:52 ` Darren New 4 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-21 15:52 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 7:41 ` How Ada " Will ` (2 preceding siblings ...) 2001-08-12 20:38 ` Tim Robinson @ 2001-08-13 13:28 ` Ted Dennison 2001-08-13 15:31 ` Martin Dowie 2001-08-22 6:17 ` Richard Riehle 5 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-13 13:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 7:41 ` How Ada " Will ` (3 preceding siblings ...) 2001-08-13 13:28 ` How Ada could have prevented the Red Code distributed denial of service attack Ted Dennison @ 2001-08-13 15:31 ` Martin Dowie 2001-08-22 6:17 ` Richard Riehle 5 siblings, 0 replies; 875+ messages in thread From: Martin Dowie @ 2001-08-13 15:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-12 7:41 ` How Ada " Will ` (4 preceding siblings ...) 2001-08-13 15:31 ` Martin Dowie @ 2001-08-22 6:17 ` Richard Riehle 2001-08-22 9:04 ` Joachim Durchholz 5 siblings, 1 reply; 875+ messages in thread From: Richard Riehle @ 2001-08-22 6:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 6:17 ` Richard Riehle @ 2001-08-22 9:04 ` Joachim Durchholz 2001-08-22 9:54 ` Larry Kilgallen 2001-08-22 10:24 ` Markus Mottl 0 siblings, 2 replies; 875+ messages in thread From: Joachim Durchholz @ 2001-08-22 9:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 9:04 ` Joachim Durchholz @ 2001-08-22 9:54 ` Larry Kilgallen 2001-08-22 10:10 ` Richard Bos 2001-08-22 10:24 ` Markus Mottl 1 sibling, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-08-22 9:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 9:54 ` Larry Kilgallen @ 2001-08-22 10:10 ` Richard Bos 2001-08-22 11:17 ` Larry Kilgallen ` (3 more replies) 0 siblings, 4 replies; 875+ messages in thread From: Richard Bos @ 2001-08-22 10:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 10:10 ` Richard Bos @ 2001-08-22 11:17 ` Larry Kilgallen 2001-08-22 12:35 ` Markus Mottl ` (2 more replies) 2001-08-22 12:18 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl ` (2 subsequent siblings) 3 siblings, 3 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-22 11:17 UTC (permalink / raw) 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 ? :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 11:17 ` Larry Kilgallen @ 2001-08-22 12:35 ` Markus Mottl 2001-08-22 12:45 ` Richard Bos 2001-08-22 13:31 ` Ted Dennison 2 siblings, 0 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-22 12:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 11:17 ` Larry Kilgallen 2001-08-22 12:35 ` Markus Mottl @ 2001-08-22 12:45 ` Richard Bos 2001-08-22 13:31 ` Ted Dennison 2 siblings, 0 replies; 875+ messages in thread From: Richard Bos @ 2001-08-22 12:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 11:17 ` Larry Kilgallen 2001-08-22 12:35 ` Markus Mottl 2001-08-22 12:45 ` Richard Bos @ 2001-08-22 13:31 ` Ted Dennison 2001-08-22 18:06 ` Adam Fineman 2 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-22 13:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 13:31 ` Ted Dennison @ 2001-08-22 18:06 ` Adam Fineman 2001-08-22 18:50 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: Adam Fineman @ 2001-08-22 18:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-22 18:06 ` Adam Fineman @ 2001-08-22 18:50 ` Ted Dennison 2001-08-22 22:10 ` Adam Fineman 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-22 18:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-22 18:50 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison @ 2001-08-22 22:10 ` Adam Fineman 2001-08-23 13:43 ` Ted Dennison 0 siblings, 1 reply; 875+ messages in thread From: Adam Fineman @ 2001-08-22 22:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-22 22:10 ` Adam Fineman @ 2001-08-23 13:43 ` Ted Dennison 2001-08-23 16:03 ` Adam Fineman 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-23 13:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 13:43 ` Ted Dennison @ 2001-08-23 16:03 ` Adam Fineman 2001-08-23 16:10 ` Gary Scott ` (2 more replies) 0 siblings, 3 replies; 875+ messages in thread From: Adam Fineman @ 2001-08-23 16:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 16:03 ` Adam Fineman @ 2001-08-23 16:10 ` Gary Scott 2001-08-23 18:01 ` Adam Fineman 2001-08-23 16:52 ` Markus Mottl 2001-08-23 18:17 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2 siblings, 1 reply; 875+ messages in thread From: Gary Scott @ 2001-08-23 16:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 16:10 ` Gary Scott @ 2001-08-23 18:01 ` Adam Fineman 0 siblings, 0 replies; 875+ messages in thread From: Adam Fineman @ 2001-08-23 18:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 16:03 ` Adam Fineman 2001-08-23 16:10 ` Gary Scott @ 2001-08-23 16:52 ` Markus Mottl 2001-08-23 17:56 ` Adam Fineman 2001-08-23 21:21 ` Tore Lund 2001-08-23 18:17 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2 siblings, 2 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-23 16:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 16:52 ` Markus Mottl @ 2001-08-23 17:56 ` Adam Fineman 2001-08-23 21:21 ` Tore Lund 1 sibling, 0 replies; 875+ messages in thread From: Adam Fineman @ 2001-08-23 17:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 16:52 ` Markus Mottl 2001-08-23 17:56 ` Adam Fineman @ 2001-08-23 21:21 ` Tore Lund 2001-08-24 17:28 ` QNX (was Re: How Ada could have prevented ...) Ray Blaak 1 sibling, 1 reply; 875+ messages in thread From: Tore Lund @ 2001-08-23 21:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* QNX (was Re: How Ada could have prevented ...) 2001-08-23 21:21 ` Tore Lund @ 2001-08-24 17:28 ` Ray Blaak 0 siblings, 0 replies; 875+ messages in thread From: Ray Blaak @ 2001-08-24 17:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 16:03 ` Adam Fineman 2001-08-23 16:10 ` Gary Scott 2001-08-23 16:52 ` Markus Mottl @ 2001-08-23 18:17 ` Ted Dennison 2 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-23 18:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 10:10 ` Richard Bos 2001-08-22 11:17 ` Larry Kilgallen @ 2001-08-22 12:18 ` Markus Mottl 2001-08-22 13:33 ` Ted Dennison 2001-08-22 13:39 ` Larry Kilgallen 2001-08-23 6:26 ` Richard Riehle 3 siblings, 1 reply; 875+ messages in thread From: Markus Mottl @ 2001-08-22 12:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 12:18 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl @ 2001-08-22 13:33 ` Ted Dennison 2001-08-22 20:29 ` Markus Mottl 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-22 13:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 13:33 ` Ted Dennison @ 2001-08-22 20:29 ` Markus Mottl 2001-08-22 21:28 ` OT: US global politics (was: How Ada could have prevented the Red Code distributed denial of service attack.) Ted Dennison 2001-08-23 4:37 ` How Ada could have prevented the Red Code distributed denial of service attack Daniel C. Wang 0 siblings, 2 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-22 20:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* OT: US global politics (was: How Ada could have prevented the Red Code distributed denial of service attack.) 2001-08-22 20:29 ` Markus Mottl @ 2001-08-22 21:28 ` Ted Dennison 2001-08-23 9:41 ` OT: US global politics Markus Mottl 2001-08-23 4:37 ` How Ada could have prevented the Red Code distributed denial of service attack Daniel C. Wang 1 sibling, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-22 21:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: OT: US global politics 2001-08-22 21:28 ` OT: US global politics (was: How Ada could have prevented the Red Code distributed denial of service attack.) Ted Dennison @ 2001-08-23 9:41 ` Markus Mottl 0 siblings, 0 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-23 9:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 20:29 ` Markus Mottl 2001-08-22 21:28 ` OT: US global politics (was: How Ada could have prevented the Red Code distributed denial of service attack.) Ted Dennison @ 2001-08-23 4:37 ` Daniel C. Wang 1 sibling, 0 replies; 875+ messages in thread From: Daniel C. Wang @ 2001-08-23 4:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 10:10 ` Richard Bos 2001-08-22 11:17 ` Larry Kilgallen 2001-08-22 12:18 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl @ 2001-08-22 13:39 ` Larry Kilgallen 2001-08-23 6:26 ` Richard Riehle 3 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-22 13:39 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 10:10 ` Richard Bos ` (2 preceding siblings ...) 2001-08-22 13:39 ` Larry Kilgallen @ 2001-08-23 6:26 ` Richard Riehle 2001-08-23 12:57 ` Vincent Marciante 2001-08-23 16:56 ` Warren W. Gay VE3WWG 3 siblings, 2 replies; 875+ messages in thread From: Richard Riehle @ 2001-08-23 6:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-23 6:26 ` Richard Riehle @ 2001-08-23 12:57 ` Vincent Marciante 2001-08-23 16:56 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: Vincent Marciante @ 2001-08-23 12:57 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-23 6:26 ` Richard Riehle 2001-08-23 12:57 ` Vincent Marciante @ 2001-08-23 16:56 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-23 16:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 9:04 ` Joachim Durchholz 2001-08-22 9:54 ` Larry Kilgallen @ 2001-08-22 10:24 ` Markus Mottl 2001-08-22 12:34 ` Joachim Durchholz ` (2 more replies) 1 sibling, 3 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-22 10:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 10:24 ` Markus Mottl @ 2001-08-22 12:34 ` Joachim Durchholz 2001-08-22 12:47 ` Markus Mottl 2001-08-22 14:47 ` Ted Dennison 2001-08-22 14:33 ` Ted Dennison 2001-08-22 17:47 ` Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) Warren W. Gay VE3WWG 2 siblings, 2 replies; 875+ messages in thread From: Joachim Durchholz @ 2001-08-22 12:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 12:34 ` Joachim Durchholz @ 2001-08-22 12:47 ` Markus Mottl 2001-08-22 14:47 ` Ted Dennison 1 sibling, 0 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-22 12:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 12:34 ` Joachim Durchholz 2001-08-22 12:47 ` Markus Mottl @ 2001-08-22 14:47 ` Ted Dennison 2001-08-22 16:13 ` Marin David Condic 1 sibling, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-22 14:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 14:47 ` Ted Dennison @ 2001-08-22 16:13 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-22 16:13 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 10:24 ` Markus Mottl 2001-08-22 12:34 ` Joachim Durchholz @ 2001-08-22 14:33 ` Ted Dennison 2001-08-22 18:28 ` Jerry Petrey ` (4 more replies) 2001-08-22 17:47 ` Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) Warren W. Gay VE3WWG 2 siblings, 5 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-22 14:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 14:33 ` Ted Dennison @ 2001-08-22 18:28 ` Jerry Petrey 2001-08-22 19:35 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-22 20:04 ` Garry Hodgson ` (3 subsequent siblings) 4 siblings, 1 reply; 875+ messages in thread From: Jerry Petrey @ 2001-08-22 18:28 UTC (permalink / raw) 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 ----------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-22 18:28 ` Jerry Petrey @ 2001-08-22 19:35 ` Ted Dennison 2001-08-23 6:43 ` Richard Riehle 0 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-22 19:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-22 19:35 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison @ 2001-08-23 6:43 ` Richard Riehle 2001-08-27 1:49 ` tmoran 0 siblings, 1 reply; 875+ messages in thread From: Richard Riehle @ 2001-08-23 6:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-23 6:43 ` Richard Riehle @ 2001-08-27 1:49 ` tmoran 0 siblings, 0 replies; 875+ messages in thread From: tmoran @ 2001-08-27 1:49 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of 2001-08-22 14:33 ` Ted Dennison 2001-08-22 18:28 ` Jerry Petrey @ 2001-08-22 20:04 ` Garry Hodgson 2001-08-22 20:39 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl ` (2 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Garry Hodgson @ 2001-08-22 20:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 14:33 ` Ted Dennison 2001-08-22 18:28 ` Jerry Petrey 2001-08-22 20:04 ` Garry Hodgson @ 2001-08-22 20:39 ` Markus Mottl [not found] ` <3B83F9D6.73CB3E02@west.rayt <3B84103F.30409430@sage.att.com> 2001-08-25 22:44 ` How Ada could have prevented the Red Code distributed denial of service attack Stefan Skoglund 4 siblings, 0 replies; 875+ messages in thread From: Markus Mottl @ 2001-08-22 20:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <3B83F9D6.73CB3E02@west.rayt <3B84103F.30409430@sage.att.com>]
* Re: How Ada could have prevented the Red Code distributed denial of [not found] ` <3B83F9D6.73CB3E02@west.rayt <3B84103F.30409430@sage.att.com> @ 2001-08-22 22:26 ` Samuel T. Harris 0 siblings, 0 replies; 875+ messages in thread From: Samuel T. Harris @ 2001-08-22 22:26 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How Ada could have prevented the Red Code distributed denial of service attack. 2001-08-22 14:33 ` Ted Dennison ` (3 preceding siblings ...) [not found] ` <3B83F9D6.73CB3E02@west.rayt <3B84103F.30409430@sage.att.com> @ 2001-08-25 22:44 ` Stefan Skoglund 4 siblings, 0 replies; 875+ messages in thread From: Stefan Skoglund @ 2001-08-25 22:44 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 10:24 ` Markus Mottl 2001-08-22 12:34 ` Joachim Durchholz 2001-08-22 14:33 ` Ted Dennison @ 2001-08-22 17:47 ` Warren W. Gay VE3WWG 2001-08-22 18:55 ` Ted Dennison 2001-08-22 20:34 ` Kaz Kylheku 2 siblings, 2 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-22 17:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 17:47 ` Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) Warren W. Gay VE3WWG @ 2001-08-22 18:55 ` Ted Dennison 2001-08-22 20:25 ` Warren W. Gay VE3WWG 2001-08-23 3:21 ` David Starner 2001-08-22 20:34 ` Kaz Kylheku 1 sibling, 2 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-22 18:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 18:55 ` Ted Dennison @ 2001-08-22 20:25 ` Warren W. Gay VE3WWG 2001-08-23 3:21 ` David Starner 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-22 20:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 18:55 ` Ted Dennison 2001-08-22 20:25 ` Warren W. Gay VE3WWG @ 2001-08-23 3:21 ` David Starner 1 sibling, 0 replies; 875+ messages in thread From: David Starner @ 2001-08-23 3:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 17:47 ` Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) Warren W. Gay VE3WWG 2001-08-22 18:55 ` Ted Dennison @ 2001-08-22 20:34 ` Kaz Kylheku 2001-08-22 21:57 ` Dale Stanbrough ` (4 more replies) 1 sibling, 5 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-22 20:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 20:34 ` Kaz Kylheku @ 2001-08-22 21:57 ` Dale Stanbrough 2001-08-23 1:56 ` Joe Maun ` (3 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Dale Stanbrough @ 2001-08-22 21:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 20:34 ` Kaz Kylheku 2001-08-22 21:57 ` Dale Stanbrough @ 2001-08-23 1:56 ` Joe Maun 2001-08-26 1:10 ` Igor Tandetnik 2001-08-26 9:13 ` Florian Weimer 2001-08-23 3:17 ` David Starner ` (2 subsequent siblings) 4 siblings, 2 replies; 875+ messages in thread From: Joe Maun @ 2001-08-23 1:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 1:56 ` Joe Maun @ 2001-08-26 1:10 ` Igor Tandetnik 2001-08-26 5:16 ` pete 2001-08-26 9:13 ` Florian Weimer 1 sibling, 1 reply; 875+ messages in thread From: Igor Tandetnik @ 2001-08-26 1:10 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-26 1:10 ` Igor Tandetnik @ 2001-08-26 5:16 ` pete 2001-08-26 15:02 ` Igor Tandetnik 0 siblings, 1 reply; 875+ messages in thread From: pete @ 2001-08-26 5:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-26 5:16 ` pete @ 2001-08-26 15:02 ` Igor Tandetnik 2001-08-27 1:52 ` Joe Maun 2001-08-27 2:59 ` Kaz Kylheku 0 siblings, 2 replies; 875+ messages in thread From: Igor Tandetnik @ 2001-08-26 15:02 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-26 15:02 ` Igor Tandetnik @ 2001-08-27 1:52 ` Joe Maun 2001-08-27 3:13 ` Igor Tandetnik 2001-08-27 2:59 ` Kaz Kylheku 1 sibling, 1 reply; 875+ messages in thread From: Joe Maun @ 2001-08-27 1:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-27 1:52 ` Joe Maun @ 2001-08-27 3:13 ` Igor Tandetnik 0 siblings, 0 replies; 875+ messages in thread From: Igor Tandetnik @ 2001-08-27 3:13 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-26 15:02 ` Igor Tandetnik 2001-08-27 1:52 ` Joe Maun @ 2001-08-27 2:59 ` Kaz Kylheku 1 sibling, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-27 2:59 UTC (permalink / raw) 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''. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 1:56 ` Joe Maun 2001-08-26 1:10 ` Igor Tandetnik @ 2001-08-26 9:13 ` Florian Weimer 2001-08-27 1:53 ` Joe Maun 1 sibling, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-08-26 9:13 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-26 9:13 ` Florian Weimer @ 2001-08-27 1:53 ` Joe Maun 2001-08-27 11:05 ` Florian Weimer 0 siblings, 1 reply; 875+ messages in thread From: Joe Maun @ 2001-08-27 1:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-27 1:53 ` Joe Maun @ 2001-08-27 11:05 ` Florian Weimer 2001-08-27 19:36 ` Joe Maun 0 siblings, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-08-27 11:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-27 11:05 ` Florian Weimer @ 2001-08-27 19:36 ` Joe Maun 2001-08-27 20:49 ` Florian Weimer 0 siblings, 1 reply; 875+ messages in thread From: Joe Maun @ 2001-08-27 19:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-27 19:36 ` Joe Maun @ 2001-08-27 20:49 ` Florian Weimer 2001-08-28 3:34 ` Joe Maun 0 siblings, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-08-27 20:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-27 20:49 ` Florian Weimer @ 2001-08-28 3:34 ` Joe Maun 2001-08-28 4:50 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: Joe Maun @ 2001-08-28 3:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 3:34 ` Joe Maun @ 2001-08-28 4:50 ` Kaz Kylheku 2001-08-28 17:14 ` Joe Maun 0 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-28 4:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 4:50 ` Kaz Kylheku @ 2001-08-28 17:14 ` Joe Maun 2001-08-28 19:00 ` Kaz Kylheku 0 siblings, 1 reply; 875+ messages in thread From: Joe Maun @ 2001-08-28 17:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 17:14 ` Joe Maun @ 2001-08-28 19:00 ` Kaz Kylheku 2001-08-28 19:13 ` Joe Maun 0 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-28 19:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 19:00 ` Kaz Kylheku @ 2001-08-28 19:13 ` Joe Maun 2001-08-28 20:47 ` Kaz Kylheku ` (3 more replies) 0 siblings, 4 replies; 875+ messages in thread From: Joe Maun @ 2001-08-28 19:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 19:13 ` Joe Maun @ 2001-08-28 20:47 ` Kaz Kylheku 2001-08-28 20:49 ` Kaz Kylheku ` (2 subsequent siblings) 3 siblings, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-28 20:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 19:13 ` Joe Maun 2001-08-28 20:47 ` Kaz Kylheku @ 2001-08-28 20:49 ` Kaz Kylheku 2001-08-28 23:18 ` Joe Maun 2001-08-29 2:14 ` Florian Weimer 2001-08-29 17:31 ` B.Gaffney 3 siblings, 1 reply; 875+ messages in thread From: Kaz Kylheku @ 2001-08-28 20:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 20:49 ` Kaz Kylheku @ 2001-08-28 23:18 ` Joe Maun 2001-08-29 2:17 ` Florian Weimer 0 siblings, 1 reply; 875+ messages in thread From: Joe Maun @ 2001-08-28 23:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 23:18 ` Joe Maun @ 2001-08-29 2:17 ` Florian Weimer 2001-08-29 2:10 ` Larry Kilgallen 0 siblings, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-08-29 2:17 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-29 2:17 ` Florian Weimer @ 2001-08-29 2:10 ` Larry Kilgallen 0 siblings, 0 replies; 875+ messages in thread From: Larry Kilgallen @ 2001-08-29 2:10 UTC (permalink / raw) 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) :-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 19:13 ` Joe Maun 2001-08-28 20:47 ` Kaz Kylheku 2001-08-28 20:49 ` Kaz Kylheku @ 2001-08-29 2:14 ` Florian Weimer 2001-08-29 17:31 ` B.Gaffney 3 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-29 2:14 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-28 19:13 ` Joe Maun ` (2 preceding siblings ...) 2001-08-29 2:14 ` Florian Weimer @ 2001-08-29 17:31 ` B.Gaffney 2001-08-29 18:19 ` Darren New 3 siblings, 1 reply; 875+ messages in thread From: B.Gaffney @ 2001-08-29 17:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-29 17:31 ` B.Gaffney @ 2001-08-29 18:19 ` Darren New 0 siblings, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-29 18:19 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 20:34 ` Kaz Kylheku 2001-08-22 21:57 ` Dale Stanbrough 2001-08-23 1:56 ` Joe Maun @ 2001-08-23 3:17 ` David Starner 2001-08-23 5:11 ` Kaz Kylheku 2001-08-23 9:12 ` Jean-Pierre Rosen [not found] ` <9m2ib <3B855750.466C59CF@yahoo.com> 4 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-23 3:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 3:17 ` David Starner @ 2001-08-23 5:11 ` Kaz Kylheku 0 siblings, 0 replies; 875+ messages in thread From: Kaz Kylheku @ 2001-08-23 5:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-22 20:34 ` Kaz Kylheku ` (2 preceding siblings ...) 2001-08-23 3:17 ` David Starner @ 2001-08-23 9:12 ` Jean-Pierre Rosen 2001-08-23 9:42 ` Richard Bos [not found] ` <9m2ib <3B855750.466C59CF@yahoo.com> 4 siblings, 1 reply; 875+ messages in thread From: Jean-Pierre Rosen @ 2001-08-23 9:12 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 9:12 ` Jean-Pierre Rosen @ 2001-08-23 9:42 ` Richard Bos 2001-08-23 12:00 ` James Rogers ` (4 more replies) 0 siblings, 5 replies; 875+ messages in thread From: Richard Bos @ 2001-08-23 9:42 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 9:42 ` Richard Bos @ 2001-08-23 12:00 ` James Rogers 2001-08-23 14:08 ` Marin David Condic 2001-08-23 13:58 ` Samuel T. Harris ` (3 subsequent siblings) 4 siblings, 1 reply; 875+ messages in thread From: James Rogers @ 2001-08-23 12:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 12:00 ` James Rogers @ 2001-08-23 14:08 ` Marin David Condic 0 siblings, 0 replies; 875+ messages in thread From: Marin David Condic @ 2001-08-23 14:08 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 9:42 ` Richard Bos 2001-08-23 12:00 ` James Rogers @ 2001-08-23 13:58 ` Samuel T. Harris 2001-08-23 14:46 ` Ted Dennison ` (2 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Samuel T. Harris @ 2001-08-23 13:58 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 9:42 ` Richard Bos 2001-08-23 12:00 ` James Rogers 2001-08-23 13:58 ` Samuel T. Harris @ 2001-08-23 14:46 ` Ted Dennison 2001-08-23 14:21 ` Richard Bos 2001-08-23 15:15 ` David Starner 2001-08-23 17:02 ` Richard Riehle 4 siblings, 1 reply; 875+ messages in thread From: Ted Dennison @ 2001-08-23 14:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 14:46 ` Ted Dennison @ 2001-08-23 14:21 ` Richard Bos 0 siblings, 0 replies; 875+ messages in thread From: Richard Bos @ 2001-08-23 14:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 9:42 ` Richard Bos ` (2 preceding siblings ...) 2001-08-23 14:46 ` Ted Dennison @ 2001-08-23 15:15 ` David Starner 2001-08-23 20:54 ` CBFalconer 2001-08-23 17:02 ` Richard Riehle 4 siblings, 1 reply; 875+ messages in thread From: David Starner @ 2001-08-23 15:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 15:15 ` David Starner @ 2001-08-23 20:54 ` CBFalconer 0 siblings, 0 replies; 875+ messages in thread From: CBFalconer @ 2001-08-23 20:54 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 9:42 ` Richard Bos ` (3 preceding siblings ...) 2001-08-23 15:15 ` David Starner @ 2001-08-23 17:02 ` Richard Riehle 4 siblings, 0 replies; 875+ messages in thread From: Richard Riehle @ 2001-08-23 17:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <9m2ib <3B855750.466C59CF@yahoo.com>]
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) [not found] ` <9m2ib <3B855750.466C59CF@yahoo.com> @ 2001-08-23 21:21 ` Dan Cross 2001-08-24 0:40 ` CBFalconer 0 siblings, 1 reply; 875+ messages in thread From: Dan Cross @ 2001-08-23 21:21 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) 2001-08-23 21:21 ` Dan Cross @ 2001-08-24 0:40 ` CBFalconer 0 siblings, 0 replies; 875+ messages in thread From: CBFalconer @ 2001-08-24 0:40 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ 2001-07-30 8:36 ` Preben Randhol @ 2001-07-30 8:36 ` Gary Lisyansky 2001-07-30 11:18 ` Gerhard Häring 2001-07-30 12:49 ` Russ Paielli 2001-07-30 15:36 ` Gerhard Häring ` (7 subsequent siblings) 9 siblings, 2 replies; 875+ messages in thread From: Gary Lisyansky @ 2001-07-30 8:36 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 8:36 ` How to make Ada a dominant language Gary Lisyansky @ 2001-07-30 11:18 ` Gerhard Häring 2001-07-30 12:01 ` Gary Lisyansky 2001-07-30 12:29 ` Preben Randhol 2001-07-30 12:49 ` Russ Paielli 1 sibling, 2 replies; 875+ messages in thread From: Gerhard Häring @ 2001-07-30 11:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 11:18 ` Gerhard Häring @ 2001-07-30 12:01 ` Gary Lisyansky 2001-07-30 12:56 ` Russ Paielli 2001-07-30 12:29 ` Preben Randhol 1 sibling, 1 reply; 875+ messages in thread From: Gary Lisyansky @ 2001-07-30 12:01 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:01 ` Gary Lisyansky @ 2001-07-30 12:56 ` Russ Paielli 2001-07-31 3:17 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Russ Paielli @ 2001-07-30 12:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:56 ` Russ Paielli @ 2001-07-31 3:17 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 3:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 11:18 ` Gerhard Häring 2001-07-30 12:01 ` Gary Lisyansky @ 2001-07-30 12:29 ` Preben Randhol 2001-07-30 13:11 ` Russ Paielli 1 sibling, 1 reply; 875+ messages in thread From: Preben Randhol @ 2001-07-30 12:29 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:29 ` Preben Randhol @ 2001-07-30 13:11 ` Russ Paielli 2001-07-30 15:45 ` Darren New 2001-07-31 8:51 ` Florian Weimer 0 siblings, 2 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-30 13:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:11 ` Russ Paielli @ 2001-07-30 15:45 ` Darren New 2001-07-30 16:00 ` Preben Randhol 2001-07-31 8:51 ` Florian Weimer 1 sibling, 1 reply; 875+ messages in thread From: Darren New @ 2001-07-30 15:45 UTC (permalink / raw) > > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 15:45 ` Darren New @ 2001-07-30 16:00 ` Preben Randhol 2001-07-30 16:26 ` Russ Paielli 2001-07-31 10:14 ` Philip Anderson 0 siblings, 2 replies; 875+ messages in thread From: Preben Randhol @ 2001-07-30 16:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:00 ` Preben Randhol @ 2001-07-30 16:26 ` Russ Paielli 2001-07-30 16:50 ` Gerhard Häring ` (2 more replies) 2001-07-31 10:14 ` Philip Anderson 1 sibling, 3 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-30 16:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:26 ` Russ Paielli @ 2001-07-30 16:50 ` Gerhard Häring 2001-07-30 17:55 ` Larry Kilgallen 2001-07-31 8:53 ` Florian Weimer 2 siblings, 0 replies; 875+ messages in thread From: Gerhard Häring @ 2001-07-30 16:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:26 ` Russ Paielli 2001-07-30 16:50 ` Gerhard Häring @ 2001-07-30 17:55 ` Larry Kilgallen 2001-07-30 17:23 ` Darren New 2001-07-31 8:53 ` Florian Weimer 2 siblings, 1 reply; 875+ messages in thread From: Larry Kilgallen @ 2001-07-30 17:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:55 ` Larry Kilgallen @ 2001-07-30 17:23 ` Darren New 2001-07-31 8:55 ` Florian Weimer 2001-07-31 9:45 ` Lutz Donnerhacke 0 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-07-30 17:23 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:23 ` Darren New @ 2001-07-31 8:55 ` Florian Weimer 2001-07-31 9:45 ` Lutz Donnerhacke 1 sibling, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-07-31 8:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 17:23 ` Darren New 2001-07-31 8:55 ` Florian Weimer @ 2001-07-31 9:45 ` Lutz Donnerhacke 1 sibling, 0 replies; 875+ messages in thread From: Lutz Donnerhacke @ 2001-07-31 9:45 UTC (permalink / raw) * 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) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:26 ` Russ Paielli 2001-07-30 16:50 ` Gerhard Häring 2001-07-30 17:55 ` Larry Kilgallen @ 2001-07-31 8:53 ` Florian Weimer 2 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-07-31 8:53 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 16:00 ` Preben Randhol 2001-07-30 16:26 ` Russ Paielli @ 2001-07-31 10:14 ` Philip Anderson 1 sibling, 0 replies; 875+ messages in thread From: Philip Anderson @ 2001-07-31 10:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:11 ` Russ Paielli 2001-07-30 15:45 ` Darren New @ 2001-07-31 8:51 ` Florian Weimer 2001-07-31 16:16 ` Darren New 1 sibling, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-07-31 8:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 8:51 ` Florian Weimer @ 2001-07-31 16:16 ` Darren New 2001-07-31 16:20 ` Florian Weimer 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-07-31 16:16 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 16:16 ` Darren New @ 2001-07-31 16:20 ` Florian Weimer 2001-07-31 16:53 ` Darren New 0 siblings, 1 reply; 875+ messages in thread From: Florian Weimer @ 2001-07-31 16:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 16:20 ` Florian Weimer @ 2001-07-31 16:53 ` Darren New 2001-07-31 17:10 ` Preben Randhol 2001-08-01 0:21 ` David Bolen 0 siblings, 2 replies; 875+ messages in thread From: Darren New @ 2001-07-31 16:53 UTC (permalink / raw) > > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 16:53 ` Darren New @ 2001-07-31 17:10 ` Preben Randhol 2001-07-31 17:28 ` Darren New 2001-08-01 0:21 ` David Bolen 1 sibling, 1 reply; 875+ messages in thread From: Preben Randhol @ 2001-07-31 17:10 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 17:10 ` Preben Randhol @ 2001-07-31 17:28 ` Darren New 2001-08-01 16:55 ` Florian Weimer 0 siblings, 1 reply; 875+ messages in thread From: Darren New @ 2001-07-31 17:28 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 17:28 ` Darren New @ 2001-08-01 16:55 ` Florian Weimer 0 siblings, 0 replies; 875+ messages in thread From: Florian Weimer @ 2001-08-01 16:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 16:53 ` Darren New 2001-07-31 17:10 ` Preben Randhol @ 2001-08-01 0:21 ` David Bolen 2001-08-01 3:33 ` David Bolen 1 sibling, 1 reply; 875+ messages in thread From: David Bolen @ 2001-08-01 0:21 UTC (permalink / raw) 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 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 0:21 ` David Bolen @ 2001-08-01 3:33 ` David Bolen 0 siblings, 0 replies; 875+ messages in thread From: David Bolen @ 2001-08-01 3:33 UTC (permalink / raw) 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 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 8:36 ` How to make Ada a dominant language Gary Lisyansky 2001-07-30 11:18 ` Gerhard Häring @ 2001-07-30 12:49 ` Russ Paielli 2001-07-30 13:13 ` Gary Lisyansky 2001-07-31 3:28 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-30 12:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:49 ` Russ Paielli @ 2001-07-30 13:13 ` Gary Lisyansky 2001-07-30 13:49 ` Russ Paielli 2001-07-31 3:28 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 875+ messages in thread From: Gary Lisyansky @ 2001-07-30 13:13 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:13 ` Gary Lisyansky @ 2001-07-30 13:49 ` Russ Paielli 2001-07-31 1:10 ` Adrian Hoe 0 siblings, 1 reply; 875+ messages in thread From: Russ Paielli @ 2001-07-30 13:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 13:49 ` Russ Paielli @ 2001-07-31 1:10 ` Adrian Hoe 0 siblings, 0 replies; 875+ messages in thread From: Adrian Hoe @ 2001-07-31 1:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 12:49 ` Russ Paielli 2001-07-30 13:13 ` Gary Lisyansky @ 2001-07-31 3:28 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 3:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ 2001-07-30 8:36 ` Preben Randhol 2001-07-30 8:36 ` How to make Ada a dominant language Gary Lisyansky @ 2001-07-30 15:36 ` Gerhard Häring 2001-07-30 22:58 ` Gary Scott ` (6 subsequent siblings) 9 siblings, 0 replies; 875+ messages in thread From: Gerhard Häring @ 2001-07-30 15:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ ` (2 preceding siblings ...) 2001-07-30 15:36 ` Gerhard Häring @ 2001-07-30 22:58 ` Gary Scott 2001-08-01 10:51 ` AG 2001-07-31 2:41 ` Warren W. Gay VE3WWG ` (5 subsequent siblings) 9 siblings, 1 reply; 875+ messages in thread From: Gary Scott @ 2001-07-30 22:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 22:58 ` Gary Scott @ 2001-08-01 10:51 ` AG 2001-08-01 17:10 ` Russ 0 siblings, 1 reply; 875+ messages in thread From: AG @ 2001-08-01 10:51 UTC (permalink / raw) "> 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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 10:51 ` AG @ 2001-08-01 17:10 ` Russ 0 siblings, 0 replies; 875+ messages in thread From: Russ @ 2001-08-01 17:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ ` (3 preceding siblings ...) 2001-07-30 22:58 ` Gary Scott @ 2001-07-31 2:41 ` Warren W. Gay VE3WWG 2001-07-31 4:24 ` Russ Paielli 2001-07-31 8:03 ` Keith Thompson ` (4 subsequent siblings) 9 siblings, 1 reply; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 2:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 2:41 ` Warren W. Gay VE3WWG @ 2001-07-31 4:24 ` Russ Paielli 2001-07-31 5:18 ` Warren W. Gay VE3WWG 2001-07-31 10:53 ` Philip Anderson 0 siblings, 2 replies; 875+ messages in thread From: Russ Paielli @ 2001-07-31 4:24 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 4:24 ` Russ Paielli @ 2001-07-31 5:18 ` Warren W. Gay VE3WWG 2001-07-31 10:53 ` Philip Anderson 1 sibling, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-07-31 5:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 4:24 ` Russ Paielli 2001-07-31 5:18 ` Warren W. Gay VE3WWG @ 2001-07-31 10:53 ` Philip Anderson 1 sibling, 0 replies; 875+ messages in thread From: Philip Anderson @ 2001-07-31 10:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ ` (4 preceding siblings ...) 2001-07-31 2:41 ` Warren W. Gay VE3WWG @ 2001-07-31 8:03 ` Keith Thompson 2001-07-31 11:16 ` Philip Anderson 2001-08-01 0:00 ` Stanley R. Allen ` (3 subsequent siblings) 9 siblings, 1 reply; 875+ messages in thread From: Keith Thompson @ 2001-07-31 8:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-31 8:03 ` Keith Thompson @ 2001-07-31 11:16 ` Philip Anderson 0 siblings, 0 replies; 875+ messages in thread From: Philip Anderson @ 2001-07-31 11:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ ` (5 preceding siblings ...) 2001-07-31 8:03 ` Keith Thompson @ 2001-08-01 0:00 ` Stanley R. Allen 2001-08-01 2:29 ` Russ ` (2 subsequent siblings) 9 siblings, 0 replies; 875+ messages in thread From: Stanley R. Allen @ 2001-08-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ ` (6 preceding siblings ...) 2001-08-01 0:00 ` Stanley R. Allen @ 2001-08-01 2:29 ` Russ 2001-08-01 7:10 ` Adrian Hoe ` (6 more replies) 2001-08-01 2:35 ` Mike Silva 2001-08-01 4:23 ` raj 9 siblings, 7 replies; 875+ messages in thread From: Russ @ 2001-08-01 2:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:29 ` Russ @ 2001-08-01 7:10 ` Adrian Hoe 2001-08-01 7:33 ` Russ 2001-08-01 7:13 ` Adrian Hoe ` (5 subsequent siblings) 6 siblings, 1 reply; 875+ messages in thread From: Adrian Hoe @ 2001-08-01 7:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 7:10 ` Adrian Hoe @ 2001-08-01 7:33 ` Russ 2001-08-01 15:00 ` Adrian Hoe 0 siblings, 1 reply; 875+ messages in thread From: Russ @ 2001-08-01 7:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 7:33 ` Russ @ 2001-08-01 15:00 ` Adrian Hoe 2001-08-01 15:58 ` Russ 0 siblings, 1 reply; 875+ messages in thread From: Adrian Hoe @ 2001-08-01 15:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 15:00 ` Adrian Hoe @ 2001-08-01 15:58 ` Russ 2001-08-01 17:32 ` Gary Scott 0 siblings, 1 reply; 875+ messages in thread From: Russ @ 2001-08-01 15:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 15:58 ` Russ @ 2001-08-01 17:32 ` Gary Scott 0 siblings, 0 replies; 875+ messages in thread From: Gary Scott @ 2001-08-01 17:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:29 ` Russ 2001-08-01 7:10 ` Adrian Hoe @ 2001-08-01 7:13 ` Adrian Hoe 2001-08-01 14:09 ` Marin David Condic 2001-08-01 7:19 ` Adrian Hoe ` (4 subsequent siblings) 6 siblings, 1 reply; 875+ messages in thread From: Adrian Hoe @ 2001-08-01 7:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 7:13 ` Adrian Hoe @ 2001-08-01 14:09 ` Marin David Condic 2001-08-01 17:55 ` Russ 0 siblings, 1 reply; 875+ messages in thread From: Marin David Condic @ 2001-08-01 14:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 14:09 ` Marin David Condic @ 2001-08-01 17:55 ` Russ 2001-08-01 18:26 ` Ted Dennison ` (4 more replies) 0 siblings, 5 replies; 875+ messages in thread From: Russ @ 2001-08-01 17:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 17:55 ` Russ @ 2001-08-01 18:26 ` Ted Dennison 2001-08-02 5:16 ` Semicolons (was: How to make Ada a dominant language) Warren W. Gay VE3WWG ` (3 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Ted Dennison @ 2001-08-01 18:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: Semicolons (was: How to make Ada a dominant language) 2001-08-01 17:55 ` Russ 2001-08-01 18:26 ` Ted Dennison @ 2001-08-02 5:16 ` Warren W. Gay VE3WWG 2001-08-02 8:53 ` How to make Ada a dominant language Stefan Nobis ` (2 subsequent siblings) 4 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-02 5:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 17:55 ` Russ 2001-08-01 18:26 ` Ted Dennison 2001-08-02 5:16 ` Semicolons (was: How to make Ada a dominant language) Warren W. Gay VE3WWG @ 2001-08-02 8:53 ` Stefan Nobis 2001-08-02 10:34 ` AG 2001-08-02 20:35 ` Barry Kelly 4 siblings, 0 replies; 875+ messages in thread From: Stefan Nobis @ 2001-08-02 8:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 17:55 ` Russ ` (2 preceding siblings ...) 2001-08-02 8:53 ` How to make Ada a dominant language Stefan Nobis @ 2001-08-02 10:34 ` AG 2001-08-02 20:35 ` Barry Kelly 4 siblings, 0 replies; 875+ messages in thread From: AG @ 2001-08-02 10:34 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 17:55 ` Russ ` (3 preceding siblings ...) 2001-08-02 10:34 ` AG @ 2001-08-02 20:35 ` Barry Kelly 4 siblings, 0 replies; 875+ messages in thread From: Barry Kelly @ 2001-08-02 20:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:29 ` Russ 2001-08-01 7:10 ` Adrian Hoe 2001-08-01 7:13 ` Adrian Hoe @ 2001-08-01 7:19 ` Adrian Hoe 2001-08-01 9:51 ` Preben Randhol ` (3 subsequent siblings) 6 siblings, 0 replies; 875+ messages in thread From: Adrian Hoe @ 2001-08-01 7:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:29 ` Russ ` (2 preceding siblings ...) 2001-08-01 7:19 ` Adrian Hoe @ 2001-08-01 9:51 ` Preben Randhol 2001-08-01 11:18 ` David Gillon ` (2 subsequent siblings) 6 siblings, 0 replies; 875+ messages in thread From: Preben Randhol @ 2001-08-01 9:51 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:29 ` Russ ` (3 preceding siblings ...) 2001-08-01 9:51 ` Preben Randhol @ 2001-08-01 11:18 ` David Gillon 2001-08-01 16:05 ` Russ 2001-08-01 17:12 ` Scott Ingram 2001-08-07 2:55 ` Lao Xiao Hai 6 siblings, 1 reply; 875+ messages in thread From: David Gillon @ 2001-08-01 11:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 11:18 ` David Gillon @ 2001-08-01 16:05 ` Russ 2001-08-02 5:21 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 875+ messages in thread From: Russ @ 2001-08-01 16:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 16:05 ` Russ @ 2001-08-02 5:21 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 875+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-02 5:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:29 ` Russ ` (4 preceding siblings ...) 2001-08-01 11:18 ` David Gillon @ 2001-08-01 17:12 ` Scott Ingram 2001-08-01 18:10 ` Russ 2001-08-07 2:55 ` Lao Xiao Hai 6 siblings, 1 reply; 875+ messages in thread From: Scott Ingram @ 2001-08-01 17:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 17:12 ` Scott Ingram @ 2001-08-01 18:10 ` Russ 2001-08-02 10:34 ` Leif Roar Moldskred 0 siblings, 1 reply; 875+ messages in thread From: Russ @ 2001-08-01 18:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 18:10 ` Russ @ 2001-08-02 10:34 ` Leif Roar Moldskred 0 siblings, 0 replies; 875+ messages in thread From: Leif Roar Moldskred @ 2001-08-02 10:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:29 ` Russ ` (5 preceding siblings ...) 2001-08-01 17:12 ` Scott Ingram @ 2001-08-07 2:55 ` Lao Xiao Hai 2001-08-07 3:56 ` Darren New 2001-08-07 7:34 ` Russ P. 6 siblings, 2 replies; 875+ messages in thread From: Lao Xiao Hai @ 2001-08-07 2:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-07 2:55 ` Lao Xiao Hai @ 2001-08-07 3:56 ` Darren New 2001-08-07 7:34 ` Russ P. 1 sibling, 0 replies; 875+ messages in thread From: Darren New @ 2001-08-07 3:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-07 2:55 ` Lao Xiao Hai 2001-08-07 3:56 ` Darren New @ 2001-08-07 7:34 ` Russ P. 2001-08-07 21:23 ` Lao Xiao Hai 1 sibling, 1 reply; 875+ messages in thread From: Russ P. @ 2001-08-07 7:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-07 7:34 ` Russ P. @ 2001-08-07 21:23 ` Lao Xiao Hai 0 siblings, 0 replies; 875+ messages in thread From: Lao Xiao Hai @ 2001-08-07 21:23 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ ` (7 preceding siblings ...) 2001-08-01 2:29 ` Russ @ 2001-08-01 2:35 ` Mike Silva 2001-08-01 4:32 ` Russ 2001-08-01 4:23 ` raj 9 siblings, 1 reply; 875+ messages in thread From: Mike Silva @ 2001-08-01 2:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 2:35 ` Mike Silva @ 2001-08-01 4:32 ` Russ 2001-08-01 4:56 ` Ed Falis 0 siblings, 1 reply; 875+ messages in thread From: Russ @ 2001-08-01 4:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 4:32 ` Russ @ 2001-08-01 4:56 ` Ed Falis 2001-08-01 10:21 ` AG 0 siblings, 1 reply; 875+ messages in thread From: Ed Falis @ 2001-08-01 4:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-08-01 4:56 ` Ed Falis @ 2001-08-01 10:21 ` AG 0 siblings, 0 replies; 875+ messages in thread From: AG @ 2001-08-01 10:21 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 875+ messages in thread
* Re: How to make Ada a dominant language 2001-07-30 7:08 How to make Ada a dominant language Russ ` (8 preceding siblings ...) 2001-08-01 2:35 ` Mike Silva @ 2001-08-01 4:23 ` raj 9 siblings, 0 replies; 875+ messages in thread From: raj @ 2001-08-01 4:23 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 875+ messages in thread
[parent not found: <Pine.LNX.4.33.0109031944490.3080-100000@lagoa.niaad.liacc.up.pt>]
* RE: Ada OS talk (was: Progress on AdaOS) [not found] <Pine.LNX.4.33.0109031944490.3080-100000@lagoa.niaad.liacc.up.pt> @ 2001-09-04 6:11 ` Robert C. Leif, Ph.D. 0 siblings, 0 replies; 875+ messages in thread From: Robert C. Leif, Ph.D. @ 2001-09-04 6:11 UTC (permalink / raw) To: comp.lang.ada From: Bob Leif To: M. A. Alves et al. I totally agree with, "To that effect I propose a generic principle of simplicity/smallness. That is why my messages have a general "downsizing" tone." However, I suspect that Ada will permit both "simplicity/smallness" and advanced functionality. If a file type is described as a generic private tagged type in the kernel, functionality can be added in the outer layers. Since one of the goals is efficiency, I would try to avoid those class-wide subprograms (methods) that require run-time dispatching. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Sent: Monday, September 03, 2001 1:13 PM To: comp.lang.ada@ada.eu.org Subject: Re: Ada OS talk (was: Progress on AdaOS) > > > 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 ^ permalink raw reply [flat|nested] 875+ messages in thread
end of thread, other threads:[~2001-12-27 12:16 UTC | newest] Thread overview: 875+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-30 7:08 How to make Ada a dominant language Russ 2001-07-30 8:36 ` Preben Randhol 2001-07-30 12:41 ` Russ Paielli 2001-07-30 12:52 ` Preben Randhol 2001-07-30 13:24 ` Russ Paielli 2001-07-30 15:47 ` Preben Randhol 2001-07-30 23:13 ` Gary Scott 2001-07-31 1:07 ` Adrian Hoe 2001-07-30 15:38 ` Darren New 2001-07-31 8:31 ` Florian Weimer 2001-07-30 12:52 ` Gary Lisyansky 2001-07-30 13:38 ` Russ Paielli 2001-07-30 13:43 ` Gary Lisyansky 2001-07-30 15:08 ` Larry Kilgallen 2001-07-30 15:02 ` Russ Paielli 2001-07-30 15:52 ` Preben Randhol 2001-07-30 17:19 ` Darren New 2001-07-31 7:35 ` Preben Randhol 2001-08-02 1:36 ` David Starner 2001-08-02 8:01 ` Larry Kilgallen 2001-08-02 8:11 ` David Starner 2001-08-02 12:11 ` Larry Kilgallen 2001-08-02 14:47 ` Ted Dennison 2001-08-02 16:10 ` Darren New 2001-08-02 19:30 ` Larry Kilgallen 2001-08-02 19:04 ` Darren New 2001-08-02 20:52 ` Larry Kilgallen 2001-08-02 16:09 ` Darren New 2001-08-02 23:39 ` bruns 2001-08-03 7:28 ` Pascal Obry 2001-08-03 18:53 ` Lao Xiao Hai 2001-08-03 13:59 ` Marin David Condic 2001-08-03 3:40 ` Larry Kilgallen 2001-07-30 16:21 ` Larry Kilgallen 2001-07-30 16:19 ` Russ Paielli 2001-07-30 16:33 ` Marin David Condic 2001-07-30 18:33 ` Stefan Nobis 2001-07-30 21:26 ` Milan Mancel 2001-07-31 3:37 ` Russ Paielli 2001-07-31 20:36 ` Milan Mancel 2001-07-31 14:37 ` Ted Dennison 2001-07-31 14:56 ` Gary Lisyansky 2001-07-31 15:07 ` Marin David Condic 2001-08-01 0:54 ` David Bolen 2001-08-01 13:17 ` Ted Dennison 2001-08-01 22:15 ` David Bolen 2001-08-01 9:11 ` Milan Mancel 2001-08-01 12:06 ` Larry Hazel 2001-08-01 13:41 ` Marin David Condic 2001-08-01 15:55 ` Larry Hazel 2001-08-01 16:56 ` Marin David Condic 2001-08-01 19:18 ` Ed Falis 2001-08-01 13:41 ` Ted Dennison 2001-08-01 13:28 ` Ted Dennison 2001-08-01 15:17 ` Scott Ingram 2001-07-31 3:06 ` Warren W. Gay VE3WWG 2001-07-31 4:10 ` Russ Paielli 2001-07-31 5:05 ` Warren W. Gay VE3WWG 2001-07-30 17:19 ` Pascal Obry 2001-07-31 3:46 ` Russ Paielli 2001-07-31 5:08 ` Warren W. Gay VE3WWG 2001-07-31 7:09 ` Pascal Obry 2001-07-31 14:17 ` Marin David Condic 2001-07-30 17:33 ` Brian Rogoff 2001-07-31 4:01 ` Russ Paielli 2001-07-31 17:31 ` Brian Rogoff 2001-07-30 17:51 ` file13 2001-07-31 14:51 ` Ted Dennison 2001-07-30 22:35 ` Attributes of a development which require Ada (Was Re: How to make Ada a dominant language) Hambut 2001-07-31 6:16 ` How to make Ada a dominant language Gary Lisyansky 2001-07-31 9:32 ` Philip Anderson 2001-07-31 10:16 ` Lutz Donnerhacke 2001-08-02 20:35 ` Barry Kelly 2001-08-03 0:07 ` Keith Thompson 2001-08-03 6:35 ` Gary Lisyansky 2001-08-16 5:19 ` David Thompson 2001-07-30 18:22 ` Stefan Nobis 2001-07-31 0:53 ` Adrian Hoe 2001-07-31 3:24 ` Russ Paielli 2001-07-31 6:47 ` Martin Dowie 2001-07-31 7:10 ` Russ Paielli 2001-07-31 7:22 ` Gary Lisyansky 2001-07-31 7:38 ` Keith Thompson 2001-07-31 8:20 ` Martin Dowie 2001-07-31 15:32 ` Ted Dennison 2001-07-31 11:16 ` David Gillon 2001-08-01 1:25 ` Adrian Hoe 2001-08-01 4:25 ` Russ 2001-08-01 8:22 ` MALAISE Pascal 2001-08-01 9:34 ` Preben Randhol 2001-08-01 10:32 ` AG 2001-08-01 15:55 ` Russ 2001-08-01 16:50 ` chris.danx 2001-08-01 15:52 ` Russ 2001-08-01 13:48 ` Stefan Nobis 2001-08-02 8:32 ` Pascal Obry 2001-08-01 10:08 ` AG 2001-07-31 8:29 ` Florian Weimer 2001-07-31 20:34 ` Keith Thompson 2001-07-31 21:29 ` The concept of := (was How to make Ada a dominant language) Warren W. Gay VE3WWG 2001-08-01 2:29 ` Keith Thompson 2001-08-01 3:27 ` How Ada could have prevented the Red Code distributed denial of service attack raj 2001-08-01 4:58 ` Martin Ambuhl 2001-08-01 5:01 ` Daniel Fischer 2001-08-01 8:24 ` raj 2001-08-01 12:55 ` Bart v Ingen Schenau 2001-08-01 18:44 ` Lawrence Foard 2001-08-01 19:58 ` Matthias Blume 2001-08-01 20:46 ` Kaz Kylheku 2001-08-01 21:21 ` Marin David Condic 2001-08-02 13:44 ` CBFalconer 2001-08-03 23:43 ` Tom Plunket 2001-08-06 7:11 ` Dave Adlam 2001-08-02 8:54 ` Richard Bos 2001-08-03 3:20 ` Zoltan Somogyi 2001-08-01 8:56 ` Richard Bos 2001-08-01 13:09 ` Mike Smith 2001-08-01 15:32 ` Preben Randhol 2001-08-01 16:24 ` Karl Heinz Buchegger 2001-08-07 23:55 ` Mark Lundquist 2001-08-01 20:36 ` Micah Cowan 2001-08-01 22:05 ` Ed Falis 2001-08-01 22:47 ` Micah Cowan 2001-08-02 3:37 ` Ed Falis 2001-08-02 13:44 ` CBFalconer 2001-08-07 20:57 ` Albert van der Horst 2001-08-09 1:25 ` How Ada could have prevented the Red Code distributed denial of Larry Kilgallen 2001-08-01 22:56 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl 2001-08-01 23:13 ` Richard Heathfield 2001-08-01 23:18 ` Kaz Kylheku 2001-08-02 4:10 ` gregm 2001-08-01 23:24 ` Markus Mottl 2001-08-02 0:05 ` Aaron Denney 2001-08-02 9:13 ` Markus Mottl 2001-08-02 13:44 ` CBFalconer 2001-08-02 0:32 ` those who know me have no need of my name 2001-08-02 7:38 ` Richard Heathfield 2001-08-02 0:20 ` Darren New 2001-08-02 1:22 ` Michael Rubenstein 2001-08-02 5:49 ` Fergus Henderson 2001-08-02 6:44 ` Chris Kuan 2001-08-03 1:08 ` Chris Kuan 2001-08-02 8:28 ` Zoltan Somogyi 2001-08-02 19:05 ` Wes Groleau 2001-08-02 3:11 ` Bruce G. Stewart 2001-08-02 3:21 ` Kaz Kylheku 2001-08-02 3:24 ` David Starner 2001-08-02 6:53 ` Kaz Kylheku 2001-08-02 9:19 ` Markus Mottl 2001-08-02 7:54 ` Preben Randhol 2001-08-01 17:32 ` Scott Ingram 2001-08-02 11:56 ` Beelsebob 2001-08-02 12:15 ` Leif Roar Moldskred 2001-08-02 13:06 ` Charles Krug 2001-08-02 14:12 ` Marin David Condic 2001-08-02 16:51 ` Scott Ingram 2001-08-02 19:21 ` How Ada could have prevented the Red Code distributed denial of Larry Kilgallen 2001-08-03 0:44 ` How Ada could have prevented the Red Code distributed denial of service attack Mike Silva 2001-08-01 17:49 ` Robert Dewar 2001-08-01 18:11 ` Ted Dennison 2001-08-01 18:40 ` Chris Torek 2001-08-01 20:04 ` Marin David Condic 2001-08-01 21:27 ` Chris Torek 2001-08-02 0:15 ` Larry Kilgallen 2001-12-27 12:16 ` Florian Weimer 2001-08-02 14:26 ` Marin David Condic 2001-08-02 19:29 ` CBFalconer 2001-08-01 23:15 ` Larry Kilgallen 2001-08-02 8:25 ` Richard Bos 2001-08-02 12:01 ` Larry Kilgallen 2001-08-02 21:52 ` Chris Torek 2001-08-03 6:05 ` Dan Cross 2001-08-03 6:17 ` Kaz Kylheku 2001-08-03 14:36 ` Dan Cross 2001-08-03 17:55 ` Kaz Kylheku 2001-08-03 18:01 ` Ben Pfaff 2001-08-03 18:23 ` Marc A. Criley 2001-08-05 3:38 ` AG 2001-08-13 20:23 ` Stefan Skoglund 2001-08-03 18:15 ` Ted Dennison 2001-08-03 19:09 ` Dan Cross 2001-08-03 20:26 ` Ted Dennison 2001-08-03 21:54 ` Tore Lund 2001-08-06 3:35 ` Keith Thompson 2001-08-06 23:36 ` Warren W. Gay VE3WWG 2001-08-06 9:30 ` kers 2001-08-03 11:24 ` Richard Bos 2001-08-03 14:41 ` Dan Cross 2001-08-06 13:51 ` Richard Bos 2001-08-06 16:07 ` Dan Cross 2001-08-07 15:12 ` Scott Ingram 2001-08-02 15:08 ` Marin David Condic 2001-08-03 0:34 ` Mike Silva 2001-08-01 21:40 ` Florian Weimer [not found] ` <GHEt6A.BzD@approve.se> 2001-08-01 22:12 ` Ed Falis [not found] ` <GHFDJp.G7q@approve.se> 2001-08-02 7:41 ` Preben Randhol [not found] ` <GHGA3t.Izq@approve.se> 2001-08-02 17:30 ` David Gillon 2001-08-02 17:37 ` Marin David Condic [not found] ` <GHGGJH.JpI@approve.se> 2001-08-02 20:11 ` Darren New 2001-08-02 20:37 ` Marin David Condic 2001-08-03 10:15 ` Reivilo Snuved 2001-08-03 14:15 ` Marin David Condic 2001-08-03 14:55 ` Reivilo Snuved 2001-08-03 14:44 ` Dan Cross 2001-08-03 15:02 ` Reivilo Snuved 2001-08-03 15:38 ` Marin David Condic 2001-08-03 17:00 ` Mike Silva 2001-08-03 17:21 ` Mike Williams 2001-08-05 21:39 ` Mike Silva 2001-08-06 14:32 ` Marin David Condic 2001-08-02 20:55 ` Dan Cross 2001-08-02 21:56 ` Warren W. Gay VE3WWG 2001-08-02 17:38 ` Scott Ingram 2001-08-02 17:54 ` Ruslan Abdikeev 2001-08-02 18:01 ` Dan Cross 2001-08-02 19:24 ` Larry Kilgallen 2001-08-02 18:44 ` Daniel Fischer 2001-08-03 7:53 ` Christian Bau 2001-08-03 8:02 ` Daniel Fischer 2001-08-03 9:27 ` Christian Bau 2001-08-03 10:01 ` Daniel Fischer 2001-08-03 14:46 ` Marin David Condic 2001-08-03 14:41 ` Marin David Condic 2001-08-04 14:11 ` Tor Rustad 2001-08-06 14:42 ` Marin David Condic 2001-08-02 19:05 ` Darren New 2001-08-02 19:29 ` CBFalconer 2001-08-02 19:25 ` Tor Rustad 2001-08-03 3:11 ` Mike Silva 2001-08-04 0:26 ` Tor Rustad 2001-08-04 2:50 ` James Rogers 2001-08-04 14:07 ` Tor Rustad 2001-08-04 14:56 ` James Rogers 2001-08-05 12:44 ` Tor Rustad 2001-08-06 0:22 ` Larry Kilgallen 2001-08-06 13:51 ` Richard Bos 2001-08-06 16:23 ` Dan Cross 2001-08-06 14:13 ` Ted Dennison 2001-08-06 16:17 ` Larry Kilgallen 2001-08-06 14:17 ` Ted Dennison 2001-08-06 14:03 ` Richard Bos 2001-08-06 15:02 ` Yoann Padioleau 2001-08-06 15:17 ` Matthias Blume 2001-08-06 16:42 ` Aaron Denney 2001-08-06 16:35 ` Aaron Denney 2001-08-07 19:43 ` David Lee Lambert 2001-08-07 20:15 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-05 22:15 ` How Ada could have prevented the Red Code distributed denial of service attack Mike Silva 2001-08-06 11:44 ` David Gillon 2001-08-06 14:59 ` Marin David Condic 2001-08-06 18:12 ` CBFalconer 2001-08-06 19:35 ` Marin David Condic 2001-08-02 13:02 ` Ed Falis 2001-08-02 15:24 ` Marin David Condic 2001-08-02 16:02 ` Reivilo Snuved 2001-08-01 18:43 ` Ted Dennison 2001-08-01 21:07 ` Mike Smith 2001-08-01 22:12 ` Dale Stanbrough 2001-08-01 22:40 ` Kaz Kylheku 2001-08-01 23:00 ` Dale Stanbrough 2001-08-02 5:00 ` Warren W. Gay VE3WWG 2001-08-02 15:53 ` Brian Rogoff 2001-08-02 8:25 ` Richard Bos 2001-08-02 10:09 ` Martin Dowie 2001-08-03 7:26 ` Richard Bos 2001-08-03 12:06 ` Martin Dowie 2001-08-02 17:30 ` CBFalconer 2001-08-05 8:06 ` Marcin 'Qrczak' Kowalczyk 2001-08-02 6:55 ` Ketil Z Malde 2001-08-01 22:44 ` Dan Cross 2001-08-01 23:29 ` Aaron Denney 2001-08-02 2:19 ` Mike Smith 2001-08-02 8:17 ` Bill Godfrey 2001-08-02 10:14 ` Martin Dowie 2001-08-02 19:23 ` Tor Rustad 2001-08-03 8:05 ` Martin Dowie 2001-08-02 15:37 ` Marin David Condic 2001-08-02 17:25 ` David Gillon 2001-08-02 15:50 ` Dan Cross 2001-08-03 6:26 ` Mike Williams 2001-08-03 14:07 ` Richard Bos 2001-08-03 14:31 ` Dan Cross [not found] ` <dale-8EE262.08123502082001@mec2. <Xz%97.2632$B37.106689@news1.rdc1.bc.home.com> 2001-08-01 22:58 ` Dan Cross 2001-08-02 8:25 ` Richard Bos 2001-08-02 9:25 ` Markus Mottl 2001-08-02 16:10 ` Dan Cross 2001-08-02 16:20 ` Daniel Fischer 2001-08-02 16:42 ` Dan Cross 2001-08-02 17:29 ` Marin David Condic 2001-08-02 18:04 ` Daniel Fischer 2001-08-02 18:06 ` Dan Cross 2001-08-02 22:58 ` Warren W. Gay VE3WWG 2001-08-03 8:25 ` CBFalconer 2001-08-06 21:26 ` Bart.Vanhauwaert 2001-08-07 0:07 ` Warren W. Gay VE3WWG 2001-08-07 0:15 ` Kaz Kylheku 2001-08-07 3:04 ` Warren W. Gay VE3WWG 2001-08-07 3:18 ` Francois Labreque 2001-08-07 4:10 ` Warren W. Gay VE3WWG 2001-08-07 5:14 ` Kaz Kylheku 2001-08-07 12:04 ` Larry Kilgallen 2001-08-07 17:16 ` Ted Dennison 2001-08-07 11:53 ` Larry Kilgallen 2001-08-07 16:12 ` Kaz Kylheku 2001-08-07 17:28 ` Ted Dennison 2001-08-07 17:56 ` Marin David Condic 2001-08-07 18:36 ` David Starner 2001-08-07 21:14 ` Larry Kilgallen 2001-08-08 7:38 ` David Starner 2001-08-07 21:49 ` Marin David Condic 2001-08-08 3:39 ` David Starner 2001-08-08 10:40 ` A Directory package for Ada (was: How Ada could have prevented) Larry Kilgallen 2001-08-07 11:57 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 2001-08-07 22:44 ` James Rogers 2001-08-08 4:04 ` Lao Xiao Hai 2001-08-08 10:00 ` Ole-Hjalmar Kristensen 2001-08-08 21:55 ` Bart.Vanhauwaert 2001-08-08 23:13 ` Larry Kilgallen 2001-08-09 13:20 ` Ted Dennison 2001-08-08 2:59 ` Warren W. Gay VE3WWG 2001-08-08 4:03 ` David Bolen 2001-08-08 4:56 ` Warren W. Gay VE3WWG 2001-08-08 23:49 ` David Bolen 2001-08-09 5:12 ` Warren W. Gay VE3WWG 2001-08-09 13:10 ` How Ada could have prevented the Red Code distributed denial Ted Dennison 2001-08-09 23:57 ` Warren W. Gay VE3WWG 2001-08-10 13:35 ` Data portability with streams Ted Dennison 2001-08-10 17:13 ` Robert Dewar 2001-08-10 19:51 ` Ted Dennison 2001-08-08 22:18 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 2001-08-09 5:30 ` Warren W. Gay VE3WWG 2001-08-09 18:10 ` Bart.Vanhauwaert 2001-08-10 0:05 ` Warren W. Gay VE3WWG 2001-08-14 12:51 ` Bertrand Augereau 2001-08-14 13:32 ` Bertrand Augereau 2001-08-14 14:39 ` Larry Hazel 2001-08-14 16:14 ` Kaz Kylheku 2001-08-14 16:26 ` Bertrand Augereau 2001-08-15 13:36 ` Martin 2001-08-15 16:47 ` Ray Blaak 2001-08-14 16:15 ` Warren W. Gay VE3WWG 2001-08-16 5:16 ` David Thompson 2001-08-16 13:19 ` Warren W. Gay VE3WWG 2001-08-16 13:25 ` Richard Bos 2001-08-16 13:44 ` Ian Wild 2001-08-16 17:32 ` Warren W. Gay VE3WWG 2001-08-16 17:53 ` Kaz Kylheku 2001-08-16 18:52 ` David C. Hoos 2001-08-16 20:40 ` Warren W. Gay VE3WWG 2001-08-16 18:23 ` Ron Natalie 2001-08-16 20:41 ` Warren W. Gay VE3WWG 2001-08-16 21:14 ` Ben Pfaff 2001-08-16 21:33 ` Ron Natalie 2001-08-17 18:10 ` Warren W. Gay VE3WWG 2001-08-20 8:22 ` Ian Wild 2001-08-16 21:34 ` Karthik Gurusamy 2001-08-16 21:36 ` Ben Pfaff 2001-08-16 17:31 ` Kaz Kylheku 2001-08-16 19:28 ` Samuel T. Harris 2001-08-19 18:14 ` Michael Rubenstein 2001-08-16 18:28 ` Clark S. Cox III [not found] ` <urTe7.71343$B37.16278 <3B7C1EF2.4DF3C7A5@gsde.hou.us.ray.com> 2001-08-16 21:49 ` Greg Comeau 2001-08-16 22:38 ` Samuel T. Harris [not found] ` <3B7BCEC4.202A3FA@cfmu <Pine.GSO.4.33.0108161431560.15612-100000@longmorn.cisco.com> 2001-08-16 22:23 ` Greg Comeau 2001-08-13 20:54 ` Stefan Skoglund 2001-08-07 16:20 ` Ted Dennison 2001-08-07 17:49 ` Marin David Condic 2001-08-08 3:14 ` Warren W. Gay VE3WWG 2001-08-08 22:34 ` Bart.Vanhauwaert 2001-08-09 5:36 ` Warren W. Gay VE3WWG 2001-08-09 18:43 ` Bart.Vanhauwaert 2001-08-10 0:23 ` Warren W. Gay VE3WWG 2001-08-10 12:29 ` Bart.Vanhauwaert 2001-08-10 15:01 ` Warren W. Gay VE3WWG 2001-08-11 9:00 ` Bart.Vanhauwaert 2001-08-11 18:19 ` Warren W. Gay VE3WWG 2001-08-09 14:18 ` Ted Dennison 2001-08-09 15:48 ` Clark S. Cox III 2001-08-09 16:52 ` Ted Dennison 2001-08-09 17:34 ` Clark S. Cox III 2001-08-09 19:23 ` Bart.Vanhauwaert 2001-08-13 21:59 ` Stefan Skoglund 2001-08-20 13:39 ` Marin David Condic 2001-08-23 17:17 ` Stefan Skoglund 2001-08-27 1:49 ` simple CPUs, was " tmoran 2001-08-27 11:08 ` Florian Weimer 2001-08-27 13:53 ` Marin David Condic 2001-08-27 14:44 ` Gary Scott 2001-08-27 18:49 ` Marin David Condic 2001-08-27 18:46 ` tmoran 2001-08-27 19:10 ` Marin David Condic 2001-08-27 23:33 ` William Dale 2001-08-28 13:38 ` Marin David Condic 2001-08-09 20:26 ` Florian Weimer 2001-08-09 21:03 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-09 19:07 ` How Ada could have prevented the Red Code distributed denial of service attack Bart.Vanhauwaert 2001-08-10 1:05 ` Warren W. Gay VE3WWG 2001-08-10 12:45 ` Bart.Vanhauwaert 2001-08-10 15:05 ` Warren W. Gay VE3WWG 2001-08-11 9:05 ` Bart.Vanhauwaert 2001-08-11 19:49 ` Matthew Woodcraft 2001-08-14 13:09 ` Bertrand Augereau 2001-08-17 0:46 ` Warren W. Gay VE3WWG 2001-08-17 1:53 ` Kaz Kylheku 2001-08-17 9:29 ` pete 2001-08-17 10:23 ` Richard Bos 2001-08-17 13:46 ` pete 2001-08-17 14:33 ` pete 2001-08-17 20:12 ` Kaz Kylheku 2001-08-20 7:02 ` pete 2001-08-20 16:39 ` Kaz Kylheku 2001-08-17 1:57 ` Chris Wolfe 2001-08-17 2:27 ` Kaz Kylheku 2001-08-17 3:42 ` Warren W. Gay VE3WWG 2001-08-17 7:33 ` Kaz Kylheku 2001-08-17 13:46 ` Warren W. Gay VE3WWG 2001-08-17 20:08 ` Kaz Kylheku 2001-08-18 5:16 ` Warren W. Gay VE3WWG 2001-08-18 22:27 ` Kaz Kylheku 2001-08-29 3:47 ` David Thompson 2001-08-29 16:00 ` Kaz Kylheku 2001-08-19 21:19 ` Bart.Vanhauwaert 2001-08-17 16:40 ` Ian 2001-08-17 14:05 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-17 22:15 ` Chris Wolfe 2001-08-17 17:11 ` How Ada could have prevented the Red Code distributed denial of service attack Matthew Austern 2001-08-10 14:16 ` Ted Dennison 2001-08-03 7:26 ` Richard Bos 2001-08-03 15:05 ` Dan Cross 2001-08-03 18:06 ` Preben Randhol 2001-08-03 19:05 ` Dan Cross 2001-08-03 19:37 ` Mark Wilden 2001-08-04 8:00 ` Preben Randhol 2001-08-06 16:48 ` Mark Wilden 2001-08-06 16:56 ` Preben Randhol 2001-08-06 17:16 ` Gerhard Häring 2001-08-06 17:34 ` Kaz Kylheku 2001-08-06 19:30 ` Preben Randhol 2001-08-06 19:42 ` Ben Pfaff 2001-08-06 22:52 ` Preben Randhol [not found] ` <QyAb7.24745$B37.4 <87zo9dug9p.fsf@pfaffben.user.msu.edu> 2001-08-06 21:08 ` Dan Cross 2001-08-06 21:28 ` Ted Dennison 2001-08-06 17:19 ` Mark Wilden 2001-08-06 19:19 ` Preben Randhol 2001-08-07 0:10 ` Warren W. Gay VE3WWG 2001-08-07 1:09 ` Chris Wolfe 2001-08-07 3:06 ` James Rogers 2001-08-07 6:11 ` Kaz Kylheku 2001-08-07 23:22 ` James Rogers 2001-08-08 0:25 ` Kaz Kylheku 2001-08-08 14:03 ` Ted Dennison 2001-08-07 7:25 ` Kaz Kylheku 2001-08-07 23:24 ` James Rogers 2001-08-07 11:05 ` Daniel Fischer 2001-08-07 23:20 ` Chris Wolfe 2001-08-07 23:32 ` Chris Wolfe 2001-08-08 4:52 ` James Rogers 2001-08-08 5:31 ` Kaz Kylheku 2001-08-08 5:36 ` Kaz Kylheku 2001-08-08 12:26 ` James Rogers 2001-08-08 14:47 ` Ted Dennison 2001-08-08 9:27 ` Ole-Hjalmar Kristensen 2001-08-08 23:08 ` Chris Wolfe 2001-08-07 3:09 ` Warren W. Gay VE3WWG 2001-08-07 22:01 ` Chris Wolfe 2001-08-08 4:18 ` Warren W. Gay VE3WWG 2001-08-08 5:00 ` Kaz Kylheku 2001-08-08 5:16 ` Warren W. Gay VE3WWG 2001-08-08 23:12 ` Chris Wolfe 2001-08-08 23:44 ` Ed Falis 2001-08-09 0:19 ` Chris Wolfe 2001-08-09 1:19 ` Ed Falis 2001-08-09 3:15 ` Kaz Kylheku 2001-08-09 5:48 ` Warren W. Gay VE3WWG 2001-08-09 14:48 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-09 23:55 ` Martin Ambuhl 2001-08-14 12:25 ` cppwiz 2001-08-14 15:39 ` Stanley R. Allen 2001-08-07 7:09 ` How Ada could have prevented the Red Code distributed denial of service attack Chris Torek 2001-08-08 4:25 ` Warren W. Gay VE3WWG 2001-08-07 12:06 ` Larry Kilgallen 2001-08-07 12:42 ` Larry Kilgallen 2001-08-09 15:25 ` How Ada could have prevented the Red Code distributed denial of Larry Kilgallen [not found] ` <3B6F3FAE.B9B9FOrganization: LJK Software <c78BbJ9nURZD@eisner.encompasserve.org> 2001-08-09 17:24 ` Ted Dennison 2001-08-03 19:56 ` How Ada could have prevented the Red Code distributed denial of service attack Ted Dennison 2001-08-06 15:21 ` Marin David Condic 2001-08-06 10:04 ` Richard Bos 2001-08-06 14:23 ` Dan Cross 2001-08-06 14:03 ` Richard Bos 2001-08-06 15:42 ` Dan Cross 2001-08-06 18:55 ` Bart.Vanhauwaert 2001-08-06 21:54 ` Dan Cross 2001-08-07 11:39 ` Bart.Vanhauwaert 2001-08-07 21:58 ` Dan Cross 2001-08-07 22:51 ` Bart.Vanhauwaert 2001-08-08 14:12 ` Dan Cross 2001-08-08 21:36 ` Bart.Vanhauwaert 2001-08-09 5:54 ` Warren W. Gay VE3WWG 2001-08-09 19:34 ` Bart.Vanhauwaert 2001-08-09 23:29 ` Mark Wilden 2001-08-10 0:46 ` Mark Wilden 2001-08-10 12:46 ` Bart.Vanhauwaert 2001-08-10 15:53 ` Mark Wilden 2001-08-10 12:04 ` Joona I Palaste 2001-08-10 1:23 ` Warren W. Gay VE3WWG 2001-08-10 14:33 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-10 15:32 ` Warren W. Gay VE3WWG 2001-08-11 3:56 ` David Starner 2001-08-11 14:10 ` Warren W. Gay VE3WWG 2001-08-11 14:27 ` Warren W. Gay VE3WWG 2001-08-09 15:57 ` How Ada could have prevented the Red Code distributed denial of service attack Marin David Condic 2001-08-09 19:42 ` Joachim Durchholz 2001-08-09 20:05 ` Larry Kilgallen 2001-08-10 6:47 ` Joachim Durchholz 2001-08-10 7:14 ` Ketil Z Malde 2001-08-09 20:09 ` Mark Wilden 2001-08-09 20:16 ` Marin David Condic 2001-08-10 5:16 ` Nicholas James NETHERCOTE 2001-08-10 6:37 ` Richard Heathfield 2001-08-10 13:40 ` Marin David Condic 2001-08-10 17:16 ` Kaz Kylheku 2001-08-13 9:27 ` Ulf Wiger 2001-08-10 8:59 ` Andreas Rossberg 2001-08-12 2:58 ` AG 2001-08-06 22:52 ` Ed Falis 2001-08-07 13:51 ` Marin David Condic 2001-08-07 22:28 ` Bart.Vanhauwaert 2001-08-07 23:06 ` Marin David Condic 2001-08-07 19:39 ` Fergus Henderson 2001-08-01 19:08 ` tmoran 2001-08-01 21:41 ` Florian Weimer 2001-08-01 23:34 ` tmoran 2001-08-02 1:29 ` Florian Weimer 2001-08-02 3:11 ` tmoran 2001-08-03 17:54 ` Dale Pontius 2001-08-05 8:23 ` Florian Weimer 2001-08-05 8:30 ` Florian Weimer 2001-08-02 21:06 ` chris.danx 2001-08-03 10:20 ` chris.danx 2001-08-03 14:00 ` Evil browser-specific web sites (was: " Ted Dennison 2001-08-03 15:27 ` Larry Kilgallen 2001-08-03 20:51 ` chris.danx 2001-08-01 22:42 ` Hartmann Schaffer 2001-08-02 1:09 ` Florian Weimer 2001-08-04 18:36 ` David Lee Lambert 2001-08-04 21:05 ` David Wagner 2001-08-05 3:00 ` How Ada could have prevented the Red Code distributed denial ofservice attack Warren W. Gay VE3WWG 2001-08-05 6:00 ` CBFalconer 2001-08-06 15:29 ` Marin David Condic 2001-08-07 2:50 ` Mike Silva 2001-08-05 8:15 ` How Ada could have prevented the Red Code distributed denial of service attack Marcin 'Qrczak' Kowalczyk 2001-08-05 9:36 ` Preben Randhol 2001-08-07 14:34 ` Attila Feher 2001-08-08 19:16 ` Simon Wright 2001-08-12 6:22 ` How a modern programming language " raj 2001-08-12 7:41 ` How Ada " Will 2001-08-12 17:38 ` Joona I Palaste 2001-08-12 18:22 ` Rajat Datta 2001-08-12 18:52 ` Dillo 2001-08-12 19:19 ` Gautier 2001-08-12 21:57 ` Tore Lund 2001-08-12 20:38 ` Tim Robinson 2001-08-12 22:02 ` tmoran 2001-08-16 1:53 ` Tony Gair 2001-08-16 13:29 ` Marin David Condic 2001-08-16 20:52 ` Warren W. Gay VE3WWG 2001-08-16 21:37 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Marin David Condic 2001-08-17 14:25 ` Ted Dennison 2001-08-17 16:36 ` Jeffrey Carter 2001-08-17 17:19 ` Marin David Condic 2001-08-17 18:04 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Ted Dennison 2001-08-17 18:09 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Warren W. Gay VE3WWG 2001-08-18 2:56 ` Robert Dewar 2001-08-18 7:32 ` David Starner 2001-08-19 6:53 ` Jeffrey Carter 2001-08-19 17:00 ` Florian Weimer 2001-08-20 14:00 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Ted Dennison 2001-08-20 14:24 ` Marin David Condic 2001-08-20 23:24 ` Didier Utheza 2001-08-21 13:43 ` Marin David Condic 2001-08-21 15:05 ` Warren W. Gay VE3WWG 2001-08-21 15:29 ` Marin David Condic 2001-08-21 17:03 ` Warren W. Gay VE3WWG 2001-08-21 22:03 ` Didier Utheza 2001-08-22 13:44 ` Marin David Condic 2001-08-22 16:30 ` Warren W. Gay VE3WWG 2001-08-22 17:03 ` Progress on AdaOS Marin David Condic 2001-08-22 18:21 ` Ted Dennison 2001-08-22 19:50 ` Marin David Condic 2001-08-22 18:23 ` Warren W. Gay VE3WWG 2001-08-22 19:54 ` Marin David Condic 2001-08-23 3:42 ` David Starner 2001-08-23 17:17 ` Open Source Approach (was Progress on AdaOS) Warren W. Gay VE3WWG 2001-08-24 1:04 ` Gerhard Häring 2001-08-24 15:27 ` Warren W. Gay VE3WWG 2001-08-23 18:36 ` Progress on AdaOS Marin David Condic 2001-08-24 1:03 ` David Starner 2001-08-24 13:47 ` Ted Dennison 2001-08-24 14:42 ` Marin David Condic 2001-08-24 16:25 ` Gary Scott 2001-08-24 16:53 ` O/S Research is Dead? (was Progress on AdaOS) Warren W. Gay VE3WWG 2001-08-24 22:01 ` Progress on AdaOS David Starner 2001-08-25 17:19 ` Gary Scott 2001-08-26 7:51 ` David Starner 2001-08-22 17:17 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Preben Randhol 2001-08-22 17:45 ` Didier Utheza 2001-08-22 19:08 ` Preben Randhol 2001-08-22 18:32 ` Progress on AdaOS Larry Kilgallen [not found] ` <Pine.A41.4.10.Organization: LJK Software <Ypd7dD0WS5sw@eisner.encompasserve.org> 2001-08-22 20:00 ` Marin David Condic 2001-08-24 20:34 ` Larry Kilgallen 2001-08-25 1:31 ` Larry Kilgallen 2001-08-25 17:11 ` David Starner 2001-08-25 19:34 ` Gary Scott 2001-08-25 20:00 ` Gary Scott 2001-08-26 7:59 ` David Starner 2001-08-26 11:47 ` Larry Kilgallen 2001-08-26 16:31 ` David Starner 2001-08-27 7:46 ` Frédéric Valdes [not found] ` <Pine.A41.4.10.Organization: LJK Software <uBW9YP9YCoMO@eisner.encompasserve.org> 2001-08-27 13:14 ` Marin David Condic 2001-08-27 17:30 ` David Starner 2001-08-27 21:08 ` Darren New 2001-08-28 1:51 ` David Starner 2001-08-28 16:13 ` Darren New 2001-08-29 3:13 ` David Starner 2001-08-29 16:42 ` Darren New 2001-08-30 6:23 ` David Starner 2001-08-30 16:37 ` Darren New 2001-08-31 16:09 ` Darren New 2001-08-31 18:42 ` M. A. Alves 2001-08-31 17:58 ` Darren New 2001-08-31 19:31 ` M. A. Alves 2001-08-31 19:54 ` Ted Dennison 2001-08-31 20:00 ` Darren New 2001-09-01 2:31 ` David Starner 2001-09-02 23:02 ` Darren New 2001-09-03 18:36 ` Ada OS talk (was: Progress on AdaOS) M. A. Alves 2001-09-03 18:11 ` Darren New 2001-09-03 20:12 ` M. A. Alves 2001-09-04 13:02 ` Marin David Condic 2001-09-04 14:34 ` Gary Scott 2001-09-04 19:44 ` Marin David Condic 2001-09-04 21:00 ` Gary Scott 2001-09-06 13:52 ` Marin David Condic 2001-09-04 17:13 ` Darren New 2001-09-04 18:34 ` Marin David Condic 2001-09-05 7:14 ` Ole-Hjalmar Kristensen 2001-09-04 21:28 ` David Starner 2001-09-05 5:06 ` Brian Catlin 2001-09-06 13:59 ` Marin David Condic 2001-09-06 21:00 ` David Starner 2001-09-07 14:24 ` Marin David Condic 2001-09-10 3:20 ` Michael Garrett 2001-09-10 12:37 ` RTEMS and Ada, Was: " Simon Clubley 2001-09-10 19:29 ` Stephen Leake 2001-09-10 20:25 ` Simon Clubley 2001-09-10 20:56 ` Joel Sherrill 2001-09-10 13:57 ` Marin David Condic 2001-09-10 20:39 ` Joel Sherrill 2001-09-11 4:04 ` Michael Garrett 2001-09-10 3:55 ` David Starner 2001-09-04 17:09 ` Darren New 2001-09-01 19:21 ` Progress on AdaOS Dmitry A. Kazakov 2001-09-02 1:09 ` Chad R. Meiners 2001-09-02 10:49 ` Dmitry A. Kazakov 2001-09-03 6:39 ` Jean-Pierre Rosen 2001-09-05 7:28 ` Dmitry Kazakov 2001-09-03 19:16 ` M. A. Alves 2001-09-05 7:47 ` Dmitry Kazakov 2001-09-05 16:37 ` Darren New 2001-09-06 12:33 ` Dmitry A. Kazakov 2001-09-06 16:35 ` Darren New 2001-09-07 7:49 ` Dmitry Kazakov 2001-09-07 15:58 ` Darren New 2001-09-08 12:02 ` Dmitry A. Kazakov 2001-09-09 2:06 ` Darren New 2001-09-09 7:46 ` Larry Kilgallen 2001-09-09 18:35 ` Dmitry A. Kazakov 2001-09-09 20:35 ` Darren New 2001-09-10 17:24 ` Dmitry A. Kazakov 2001-09-10 18:16 ` Darren New 2001-08-31 23:51 ` Brian Catlin 2001-09-01 23:46 ` Keith Thompson 2001-09-03 18:54 ` M. A. Alves 2001-09-09 0:43 ` David Thompson 2001-09-10 10:53 ` M. A. Alves 2001-09-10 18:11 ` David Starner 2001-09-11 10:45 ` M. A. Alves 2001-08-29 15:56 ` Samuel T. Harris 2001-08-28 11:07 ` Ole-Hjalmar Kristensen [not found] ` <Pine.A41.4.10.Organization: LJK Software <QzMRgPYPkyBy@eisner.encompasserve.org> 2001-08-27 13:27 ` Marin David Condic 2001-08-27 23:21 ` Samuel Tardieu 2001-08-28 13:22 ` Marin David Condic 2001-08-29 8:19 ` Samuel Tardieu 2001-08-29 14:50 ` Tony Gair 2001-08-29 15:31 ` Samuel Tardieu 2001-09-09 20:34 ` Richard Riehle 2001-08-27 23:30 ` Larry Kilgallen [not found] ` <uBW9YP9YCoMO@eOrganization: LJK Software <sy8cXTZt45T9@eisner.encompasserve.org> 2001-08-28 15:48 ` Steffen Huber 2001-08-21 21:21 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red David Starner 2001-08-22 14:03 ` Marin David Condic 2001-08-22 16:42 ` Ted Dennison 2001-08-22 17:22 ` Preben Randhol 2001-08-22 21:09 ` Marin David Condic 2001-08-23 8:50 ` Steinar Knutsen 2001-08-22 22:15 ` David Starner 2001-08-23 17:29 ` Warren W. Gay VE3WWG 2001-08-21 20:50 ` David Starner 2001-08-22 1:50 ` Warren W. Gay VE3WWG 2001-08-22 13:50 ` OT: Progress on AdaOS David Starner 2001-08-21 15:52 ` Progress on AdaOS (Was: Re: How Ada could have prevented the Red Code distributed denial of service attack.) Darren New 2001-08-13 13:28 ` How Ada could have prevented the Red Code distributed denial of service attack Ted Dennison 2001-08-13 15:31 ` Martin Dowie 2001-08-22 6:17 ` Richard Riehle 2001-08-22 9:04 ` Joachim Durchholz 2001-08-22 9:54 ` Larry Kilgallen 2001-08-22 10:10 ` Richard Bos 2001-08-22 11:17 ` Larry Kilgallen 2001-08-22 12:35 ` Markus Mottl 2001-08-22 12:45 ` Richard Bos 2001-08-22 13:31 ` Ted Dennison 2001-08-22 18:06 ` Adam Fineman 2001-08-22 18:50 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-22 22:10 ` Adam Fineman 2001-08-23 13:43 ` Ted Dennison 2001-08-23 16:03 ` Adam Fineman 2001-08-23 16:10 ` Gary Scott 2001-08-23 18:01 ` Adam Fineman 2001-08-23 16:52 ` Markus Mottl 2001-08-23 17:56 ` Adam Fineman 2001-08-23 21:21 ` Tore Lund 2001-08-24 17:28 ` QNX (was Re: How Ada could have prevented ...) Ray Blaak 2001-08-23 18:17 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-22 12:18 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl 2001-08-22 13:33 ` Ted Dennison 2001-08-22 20:29 ` Markus Mottl 2001-08-22 21:28 ` OT: US global politics (was: How Ada could have prevented the Red Code distributed denial of service attack.) Ted Dennison 2001-08-23 9:41 ` OT: US global politics Markus Mottl 2001-08-23 4:37 ` How Ada could have prevented the Red Code distributed denial of service attack Daniel C. Wang 2001-08-22 13:39 ` Larry Kilgallen 2001-08-23 6:26 ` Richard Riehle 2001-08-23 12:57 ` Vincent Marciante 2001-08-23 16:56 ` Warren W. Gay VE3WWG 2001-08-22 10:24 ` Markus Mottl 2001-08-22 12:34 ` Joachim Durchholz 2001-08-22 12:47 ` Markus Mottl 2001-08-22 14:47 ` Ted Dennison 2001-08-22 16:13 ` Marin David Condic 2001-08-22 14:33 ` Ted Dennison 2001-08-22 18:28 ` Jerry Petrey 2001-08-22 19:35 ` How Ada could have prevented the Red Code distributed denial of Ted Dennison 2001-08-23 6:43 ` Richard Riehle 2001-08-27 1:49 ` tmoran 2001-08-22 20:04 ` Garry Hodgson 2001-08-22 20:39 ` How Ada could have prevented the Red Code distributed denial of service attack Markus Mottl [not found] ` <3B83F9D6.73CB3E02@west.rayt <3B84103F.30409430@sage.att.com> 2001-08-22 22:26 ` How Ada could have prevented the Red Code distributed denial of Samuel T. Harris 2001-08-25 22:44 ` How Ada could have prevented the Red Code distributed denial of service attack Stefan Skoglund 2001-08-22 17:47 ` Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) Warren W. Gay VE3WWG 2001-08-22 18:55 ` Ted Dennison 2001-08-22 20:25 ` Warren W. Gay VE3WWG 2001-08-23 3:21 ` David Starner 2001-08-22 20:34 ` Kaz Kylheku 2001-08-22 21:57 ` Dale Stanbrough 2001-08-23 1:56 ` Joe Maun 2001-08-26 1:10 ` Igor Tandetnik 2001-08-26 5:16 ` pete 2001-08-26 15:02 ` Igor Tandetnik 2001-08-27 1:52 ` Joe Maun 2001-08-27 3:13 ` Igor Tandetnik 2001-08-27 2:59 ` Kaz Kylheku 2001-08-26 9:13 ` Florian Weimer 2001-08-27 1:53 ` Joe Maun 2001-08-27 11:05 ` Florian Weimer 2001-08-27 19:36 ` Joe Maun 2001-08-27 20:49 ` Florian Weimer 2001-08-28 3:34 ` Joe Maun 2001-08-28 4:50 ` Kaz Kylheku 2001-08-28 17:14 ` Joe Maun 2001-08-28 19:00 ` Kaz Kylheku 2001-08-28 19:13 ` Joe Maun 2001-08-28 20:47 ` Kaz Kylheku 2001-08-28 20:49 ` Kaz Kylheku 2001-08-28 23:18 ` Joe Maun 2001-08-29 2:17 ` Florian Weimer 2001-08-29 2:10 ` Larry Kilgallen 2001-08-29 2:14 ` Florian Weimer 2001-08-29 17:31 ` B.Gaffney 2001-08-29 18:19 ` Darren New 2001-08-23 3:17 ` David Starner 2001-08-23 5:11 ` Kaz Kylheku 2001-08-23 9:12 ` Jean-Pierre Rosen 2001-08-23 9:42 ` Richard Bos 2001-08-23 12:00 ` James Rogers 2001-08-23 14:08 ` Marin David Condic 2001-08-23 13:58 ` Samuel T. Harris 2001-08-23 14:46 ` Ted Dennison 2001-08-23 14:21 ` Richard Bos 2001-08-23 15:15 ` David Starner 2001-08-23 20:54 ` CBFalconer 2001-08-23 17:02 ` Richard Riehle [not found] ` <9m2ib <3B855750.466C59CF@yahoo.com> 2001-08-23 21:21 ` Dan Cross 2001-08-24 0:40 ` CBFalconer 2001-07-30 8:36 ` How to make Ada a dominant language Gary Lisyansky 2001-07-30 11:18 ` Gerhard Häring 2001-07-30 12:01 ` Gary Lisyansky 2001-07-30 12:56 ` Russ Paielli 2001-07-31 3:17 ` Warren W. Gay VE3WWG 2001-07-30 12:29 ` Preben Randhol 2001-07-30 13:11 ` Russ Paielli 2001-07-30 15:45 ` Darren New 2001-07-30 16:00 ` Preben Randhol 2001-07-30 16:26 ` Russ Paielli 2001-07-30 16:50 ` Gerhard Häring 2001-07-30 17:55 ` Larry Kilgallen 2001-07-30 17:23 ` Darren New 2001-07-31 8:55 ` Florian Weimer 2001-07-31 9:45 ` Lutz Donnerhacke 2001-07-31 8:53 ` Florian Weimer 2001-07-31 10:14 ` Philip Anderson 2001-07-31 8:51 ` Florian Weimer 2001-07-31 16:16 ` Darren New 2001-07-31 16:20 ` Florian Weimer 2001-07-31 16:53 ` Darren New 2001-07-31 17:10 ` Preben Randhol 2001-07-31 17:28 ` Darren New 2001-08-01 16:55 ` Florian Weimer 2001-08-01 0:21 ` David Bolen 2001-08-01 3:33 ` David Bolen 2001-07-30 12:49 ` Russ Paielli 2001-07-30 13:13 ` Gary Lisyansky 2001-07-30 13:49 ` Russ Paielli 2001-07-31 1:10 ` Adrian Hoe 2001-07-31 3:28 ` Warren W. Gay VE3WWG 2001-07-30 15:36 ` Gerhard Häring 2001-07-30 22:58 ` Gary Scott 2001-08-01 10:51 ` AG 2001-08-01 17:10 ` Russ 2001-07-31 2:41 ` Warren W. Gay VE3WWG 2001-07-31 4:24 ` Russ Paielli 2001-07-31 5:18 ` Warren W. Gay VE3WWG 2001-07-31 10:53 ` Philip Anderson 2001-07-31 8:03 ` Keith Thompson 2001-07-31 11:16 ` Philip Anderson 2001-08-01 0:00 ` Stanley R. Allen 2001-08-01 2:29 ` Russ 2001-08-01 7:10 ` Adrian Hoe 2001-08-01 7:33 ` Russ 2001-08-01 15:00 ` Adrian Hoe 2001-08-01 15:58 ` Russ 2001-08-01 17:32 ` Gary Scott 2001-08-01 7:13 ` Adrian Hoe 2001-08-01 14:09 ` Marin David Condic 2001-08-01 17:55 ` Russ 2001-08-01 18:26 ` Ted Dennison 2001-08-02 5:16 ` Semicolons (was: How to make Ada a dominant language) Warren W. Gay VE3WWG 2001-08-02 8:53 ` How to make Ada a dominant language Stefan Nobis 2001-08-02 10:34 ` AG 2001-08-02 20:35 ` Barry Kelly 2001-08-01 7:19 ` Adrian Hoe 2001-08-01 9:51 ` Preben Randhol 2001-08-01 11:18 ` David Gillon 2001-08-01 16:05 ` Russ 2001-08-02 5:21 ` Warren W. Gay VE3WWG 2001-08-01 17:12 ` Scott Ingram 2001-08-01 18:10 ` Russ 2001-08-02 10:34 ` Leif Roar Moldskred 2001-08-07 2:55 ` Lao Xiao Hai 2001-08-07 3:56 ` Darren New 2001-08-07 7:34 ` Russ P. 2001-08-07 21:23 ` Lao Xiao Hai 2001-08-01 2:35 ` Mike Silva 2001-08-01 4:32 ` Russ 2001-08-01 4:56 ` Ed Falis 2001-08-01 10:21 ` AG 2001-08-01 4:23 ` raj [not found] <Pine.LNX.4.33.0109031944490.3080-100000@lagoa.niaad.liacc.up.pt> 2001-09-04 6:11 ` Ada OS talk (was: Progress on AdaOS) Robert C. Leif, Ph.D.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox