* Re: status of PL/I as a viable language @ 2003-02-20 23:00 David C. Hoos, Sr. 0 siblings, 0 replies; 113+ messages in thread From: David C. Hoos, Sr. @ 2003-02-20 23:00 UTC (permalink / raw) To: comp.lang.ada mail to news gateway ----- Original Message ----- From: "Peter Flass" <peter_flass@yahoo.com> Newsgroups: comp.lang.pl1,comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: February 20, 2003 4:06 PM Subject: Re: status of PL/I as a viable language > "John R. Strohm" wrote: > > The last bug I found and fixed at my last employer was a null pointer > > access. That company has an internal coding policy that pointers will > > ALWAYS be tested for null before being dereferenced. > > I would submit that this should be done by hardware, not software (i.e. > location 0, assuming null is 0) should be fetch-protected from > everywhere but a few O/S routines. Anything else is a colossal waste of > computing resources. Well, that's probably what happened in this case. This would cause a segmentation fault, which would probably require more computing resource to recover from, as it would to test the pointer for null and take the appropriate action -- i.e., handling a signal costs more than testing the value of a register for zero/non-zero. > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > > ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language @ 2003-02-26 20:55 David C. Hoos 2003-02-27 12:12 ` Preben Randhol 0 siblings, 1 reply; 113+ messages in thread From: David C. Hoos @ 2003-02-26 20:55 UTC (permalink / raw) To: comp.lang.ada mail to news gateway ----- Original Message ----- From: "Stephen Leake" <Stephen.A.Leake@nasa.gov> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: Wednesday, February 26, 2003 12:49 PM Subject: Re: status of PL/I as a viable language > Preben Randhol <randhol+news@pvv.org> writes: > <snip> > Not quite: it really is a buffer overflow :). > > I suppose the term "buffer overflow" has been overloaded to mean > "buffer overflow that allows security breaches". But in this context, > I think the more narrow meaning is appropriate. Well... if you waant to talk about narrow meanings -- how about "attempted buffer overflow," which succeeds with C, and fails with Ada. In my view, the meaning of buffer overflow is when the buffer really overflows, not when a buffer overflow is attempted. > > -- > -- Stephe > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-26 20:55 David C. Hoos @ 2003-02-27 12:12 ` Preben Randhol 0 siblings, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-27 12:12 UTC (permalink / raw) David C. Hoos wrote: > Well... if you waant to talk about narrow meanings -- how about > "attempted buffer overflow," which succeeds with C, and fails with Ada. > > In my view, the meaning of buffer overflow is when the buffer really > overflows, not when a buffer overflow is attempted. Yes! Like a bathtub without a hole in the top to prevent overflowing (C) and a bathtub which has one so the tub only can fill to its maximum capacity (Ada). Only in the first place you can say that the tub was overflown with water. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language @ 2003-02-22 13:26 David C. Hoos, Sr. 0 siblings, 0 replies; 113+ messages in thread From: David C. Hoos, Sr. @ 2003-02-22 13:26 UTC (permalink / raw) To: comp.lang.ada mail to news gateway ----- Original Message ----- From: "John W. Kennedy" <jwkenne@attglobal.net> Newsgroups: comp.lang.pl1,comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: February 21, 2003 10:51 PM Subject: Re: status of PL/I as a viable language > Pointless Harlows wrote: > > You may recall the perfect IBM mainframe utility routine IEFBR14 ;-) > > > However, I did hear it said once that even the first version of IEFBR14 had > > a fault in that it didnt return a zero return code. > > Can anyone actually confirm that? > > The story is quite true; I remember it well. > > It had a second fault; it wasn't tagged re-entrant. > > I've heard that it had a third, but it must have been documentation-only. > > Of course, every "Hello World" program is perfect. > > And I once tested a Julian-date converter (the _real_ Julian date -- > serially numbered days from January 1, 4713 BC) to exhaustion, so it was > perfect, too. How "perfect" was it? Did it take into account the varying dates on which different parts of the world changed from the Julian to the Gregorian calendar? I'd wager it wasn't really "perfect," after all. > > -- > John W. Kennedy > "The poor have sometimes objected to being governed badly; > the rich have always objected to being governed at all." > -- G. K. Chesterton, "The Man Who Was Thursday" > > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > > ^ permalink raw reply [flat|nested] 113+ messages in thread
* RE: status of PL/I as a viable language @ 2003-02-21 18:17 Lionel.DRAGHI 2003-02-21 18:44 ` Hyman Rosen 0 siblings, 1 reply; 113+ messages in thread From: Lionel.DRAGHI @ 2003-02-21 18:17 UTC (permalink / raw) To: comp.lang.ada | -----Message d'origine----- | De: Hyman Rosen [mailto:hyrosen@mail.com] ... | | And so is this an illustration of how Ada would have helped, | or an illustration of how Ada would not have helped? Had Ada | code raised a numeric error at the overflow, would that have | caused the missile to engage its target properly? | Ada would have possibly helped by raising an obvious exception during tests, so that the software would have being fixed before flying. No one think Ada is magic enough to prevent from all complex bugs, but it's the cheapest way to reach some quality level. Lionel Draghi ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 18:17 Lionel.DRAGHI @ 2003-02-21 18:44 ` Hyman Rosen 0 siblings, 0 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 18:44 UTC (permalink / raw) Lionel.DRAGHI@fr.thalesgroup.com wrote: > Ada would have possibly helped by raising an obvious > exception during tests, so that the software would > have being fixed before flying. The claim was that the bug happened because the system had been left running for more time than its designers had anticipated. How then could an exception have been raised during testing? ^ permalink raw reply [flat|nested] 113+ messages in thread
[parent not found: <mHZ0a.42983$jM5.108891@newsfeeds.bigpond.com>]
[parent not found: <nRg1a.190899$HG.32437469@news4.srv.hcvlny.cv.net>]
[parent not found: <3E51908E.9CCA3412@adaworks.com>]
[parent not found: <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net>]
[parent not found: <3E51ABCE.5491B9A2@adaworks.com>]
[parent not found: <b2spe6$p23$1@helle.btinternet.com>]
[parent not found: <3E5273DE.2050206@cox.net>]
[parent not found: <3E531E6F.BDFB2599@adaworks.com>]
[parent not found: <3E546C45.4010406@cox.net>]
* Re: status of PL/I as a viable language [not found] ` <3E546C45.4010406@cox.net> @ 2003-02-20 15:49 ` Richard Riehle 2003-02-20 16:26 ` Donald L. Dobbs 2003-02-20 17:58 ` Hyman Rosen 0 siblings, 2 replies; 113+ messages in thread From: Richard Riehle @ 2003-02-20 15:49 UTC (permalink / raw) "Donald L. Dobbs" wrote: > Richard Riehle wrote: > > "Donald L. Dobbs" wrote: > > >>PS: ADA ain't that great. Even with the Pentagon's (DoD) legislative > >>fiat they couldn't achieve widespread adoption. It proved to be far too > >>clunky for its original intent which was embedded real-time applications > >>such as radar and fire-control systems. Over time ADA will join Pascal > >>as one of the wannabes that just didn't have enduring traction. > > > > > > Actually, Ada is that great ... > > > > > > It is used (I know this from first hand experience) very successfully > > in a large number of embedded weapon systems, embedded avionics, > > embedded commercial systems. It flies airplanes (all the software > > in the Boeing 777), drives communication satellites, controls electrical > > power plants (including nuclear), and keeps ships active at sea. It > > is the primary language of the F-22, among others. > > Not to belabor a point, but one of the lead stories today on the > Aviation Week web site www.aviationnow.com describes how the F-22 > program is now some $800 million overrun because of delays caused by > unreliable software. They can get it to run for about 8 hrs in the lab > before it crashes, but in the actual test flights it fails within 3.5 > hours forcing the pilot to reboot the system while in mid-flight. If > they are using Ada as you contend, then this is a terrible indictment > and confirms what I had heard earlier about the language's shortcomings. Donald, I will cross-post this to comp.lang.ada. The F-22 is one of the most complex systems, software and hardware, even conceived. As we discussed earlier, with regard to other language environments, the quality of the available tools can help only so much. Ada is designed to maximize the amount of error checking possible as early in the development process as possible. I know of no other language does this as well as Ada. As stated earlier, competent people have used Ada for a wide variety of successful large-scale, safety-critical software systems. On the other hand, less competent people have used Ada, PL/I, C++, C, etc. for a wide variety of unsuccessful systems. At least one Ada failure that I know of by reports from participants rather than from first-hand knowledge was an Air Traffic Control system. The people who were managing the system blamed Ada when they, the managers, were the real problem. At that time, other ATC systems had already been completed in Ada and were successfully doing their job. The problem is not the language. As someone else once said, "A fool with a tool is still a fool." From my vantage point, having a fairly broad experience with a lot of programming languages, Ada, once it is understood, continues to be the most appropriate choice for systems such as the F-22. The fact that developers can find a way to screw it up does not detract from the value of the language. If they can make a mess using a language with the rigorous controls built into Ada, imagine the magnitude of the mess they could make with, say, C++. And, no, PL/I would not help with a system this large and complex. Richard Riehle ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 15:49 ` Richard Riehle @ 2003-02-20 16:26 ` Donald L. Dobbs 2003-02-20 17:15 ` Preben Randhol 2003-02-21 6:24 ` Anders Wirzenius 2003-02-20 17:58 ` Hyman Rosen 1 sibling, 2 replies; 113+ messages in thread From: Donald L. Dobbs @ 2003-02-20 16:26 UTC (permalink / raw) Richard Riehle wrote: > "Donald L. Dobbs" wrote: > > >>Richard Riehle wrote: >> >>>"Donald L. Dobbs" wrote: >> >>>>PS: ADA ain't that great. Even with the Pentagon's (DoD) legislative >>>>fiat they couldn't achieve widespread adoption. It proved to be far too >>>>clunky for its original intent which was embedded real-time applications >>>>such as radar and fire-control systems. Over time ADA will join Pascal >>>>as one of the wannabes that just didn't have enduring traction. >>> >>> >>>Actually, Ada is that great ... >>> >>> >>>It is used (I know this from first hand experience) very successfully >>>in a large number of embedded weapon systems, embedded avionics, >>>embedded commercial systems. It flies airplanes (all the software >>>in the Boeing 777), drives communication satellites, controls electrical >>>power plants (including nuclear), and keeps ships active at sea. It >>>is the primary language of the F-22, among others. >> >>Not to belabor a point, but one of the lead stories today on the >>Aviation Week web site www.aviationnow.com describes how the F-22 >>program is now some $800 million overrun because of delays caused by >>unreliable software. They can get it to run for about 8 hrs in the lab >>before it crashes, but in the actual test flights it fails within 3.5 >>hours forcing the pilot to reboot the system while in mid-flight. If >>they are using Ada as you contend, then this is a terrible indictment >>and confirms what I had heard earlier about the language's shortcomings. > > > Donald, > > I will cross-post this to comp.lang.ada. > > The F-22 is one of the most complex systems, software and > hardware, even conceived. As we discussed earlier, with > regard to other language environments, the quality of the > available tools can help only so much. > > Ada is designed to maximize the amount of error checking possible > as early in the development process as possible. I know of no other language > does this as well as Ada. As stated earlier, competent people have used > Ada for a wide variety of successful large-scale, safety-critical software > systems. On the other hand, less competent people have used Ada, PL/I, > C++, C, etc. for a wide variety of unsuccessful systems. At least one > Ada failure that I know of by reports from participants rather than from > first-hand knowledge was an Air Traffic Control system. The people > who were managing the system blamed Ada when they, the managers, > were the real problem. At that time, other ATC systems had already > been completed in Ada and were successfully doing their job. The > problem is not the language. As someone else once said, "A fool > with a tool is still a fool." From my vantage point, having a fairly > broad experience with a lot of programming languages, Ada, once it > is understood, continues to be the most appropriate choice for systems > such as the F-22. The fact that developers can find a way to screw it > up does not detract from the value of the language. If they can make > a mess using a language with the rigorous controls built into Ada, > imagine the magnitude of the mess they could make with, say, C++. > And, no, PL/I would not help with a system this large and complex. > > Richard Riehle > Richard, You're right in that good (really good) programmers can produce successful code not matter what tools (languages) they have to tolerate while poor programmers (or at least poorly trained) will screw it up no matter how good or bulletproof the language. Your ATC example undoubtedly proves the point. Regards, -- Don. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 16:26 ` Donald L. Dobbs @ 2003-02-20 17:15 ` Preben Randhol 2003-02-21 6:24 ` Anders Wirzenius 1 sibling, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-20 17:15 UTC (permalink / raw) Donald L. Dobbs wrote: > Richard, > > You're right in that good (really good) programmers can produce > successful code not matter what tools (languages) they have to tolerate > while poor programmers (or at least poorly trained) will screw it up no > matter how good or bulletproof the language. Your ATC example > undoubtedly proves the point. Yes, but if you are a good programmer you would want to use the most appropriate tool. Espceially when time is not something you have a lot of in a project. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 16:26 ` Donald L. Dobbs 2003-02-20 17:15 ` Preben Randhol @ 2003-02-21 6:24 ` Anders Wirzenius 2003-02-21 18:44 ` John R. Strohm 1 sibling, 1 reply; 113+ messages in thread From: Anders Wirzenius @ 2003-02-21 6:24 UTC (permalink / raw) "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message news:3E550205.1010702@cox.net... > > > Richard Riehle wrote: ... > > such as the F-22. The fact that developers can find a way to screw it > > up does not detract from the value of the language. If they can make > > a mess using a language with the rigorous controls built into Ada, > > imagine the magnitude of the mess they could make with, say, C++. > > And, no, PL/I would not help with a system this large and complex. > > > > Richard Riehle > > > Richard, > > You're right in that good (really good) programmers can produce > successful code not matter what tools (languages) they have to tolerate > while poor programmers (or at least poorly trained) will screw it up no > matter how good or bulletproof the language. Your ATC example > undoubtedly proves the point. > > Regards, > > -- Don. The masters are masters and the poor are poor. The majority of the programmers are just mediocre human beings like me (and you). The interesting question could be: What are the tools that helps us to do a good job? Anders ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 6:24 ` Anders Wirzenius @ 2003-02-21 18:44 ` John R. Strohm 0 siblings, 0 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-21 18:44 UTC (permalink / raw) "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:ZCj5a.24$m%2.4@read3.inet.fi... > > "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message news:3E550205.1010702@cox.net... > > > > > > Richard Riehle wrote: > ... > > > such as the F-22. The fact that developers can find a way to screw it > > > up does not detract from the value of the language. If they can make > > > a mess using a language with the rigorous controls built into Ada, > > > imagine the magnitude of the mess they could make with, say, C++. > > > And, no, PL/I would not help with a system this large and complex. > > > > > > Richard Riehle > > > > > Richard, > > > > You're right in that good (really good) programmers can produce > > successful code not matter what tools (languages) they have to tolerate > > while poor programmers (or at least poorly trained) will screw it up no > > matter how good or bulletproof the language. Your ATC example > > undoubtedly proves the point. > > > > Regards, > > > > -- Don. > > The masters are masters and the poor are poor. > The majority of the programmers are just mediocre human beings like me (and you). > The interesting question could be: > What are the tools that helps us to do a good job? Some years ago, in a discussion with a coworker, I opined that there were three levels of programmer: novice (or apprentice), journeyman, master. He added a fourth: wizard. The REAL interesting question is: what are the appropriate tools that help each level to do a "good" job? The related question is: to what extent can the tools of e.g. a wizard be made SAFELY available to a novice? The overriding question is: how do we structure our projects and our project teams and our toolsets to allow each level of programmer to achieve maximum productivity? That last question, incidentally, reflects back on the Joel Aron/Harlan Mills "Chief Programmer Team" concept. It is well-known in computing that there may be as much as two orders of magnitude difference between programmers. It is utter idiocy to expect a low-end programmer to perform at the level of a Chief Programmer, and it is even more idiotic to restrain a Chief Programmer so he is only allowed to perform at the level of a low-end coder. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 15:49 ` Richard Riehle 2003-02-20 16:26 ` Donald L. Dobbs @ 2003-02-20 17:58 ` Hyman Rosen 2003-02-20 18:44 ` John R. Strohm 2003-02-21 20:16 ` Shmuel (Seymour J.) Metz 1 sibling, 2 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-20 17:58 UTC (permalink / raw) Richard Riehle wrote: > Ada is designed to maximize the amount of error checking possible > as early in the development process as possible. The problem is that those errors which are caught are gross errors of coding - buffer overruns, null pointer accesses, arithmetic overflow, etc. But serious errors in complex software aren't caused (only) by these sorts of errors. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 17:58 ` Hyman Rosen @ 2003-02-20 18:44 ` John R. Strohm 2003-02-20 19:09 ` Larry Kilgallen ` (7 more replies) 2003-02-21 20:16 ` Shmuel (Seymour J.) Metz 1 sibling, 8 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-20 18:44 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1045763933.848350@master.nyc.kbcfp.com... > Richard Riehle wrote: > > Ada is designed to maximize the amount of error checking possible > > as early in the development process as possible. > > The problem is that those errors which are caught are gross errors > of coding - buffer overruns, null pointer accesses, arithmetic > overflow, etc. But serious errors in complex software aren't caused > (only) by these sorts of errors. So what's your point? Are you trying to say you DON'T want to catch those "gross errors of coding - buffer overruns, null pointer accesses, arithmetic overflow, etc."? Any one of those "gross errors of coding" can and will crash an embedded system, or, worse, cause it to fail in a bad way. It was an overflowed counter that caused a Patriot battery not to engage an incoming Scud, resulting in the deaths of several U.S. servicemen. The list of Microsoft buffer overruns that have been exploited by virus authors is probably a LOT longer than your johnson. I saw a lot of VAX access violations on two different TI products, years ago. All of those errors CAN AND DO escape the development process, and they CAN AND DO cause headaches for end users. The last bug I found and fixed at my last employer was a null pointer access. That company has an internal coding policy that pointers will ALWAYS be tested for null before being dereferenced. They have mandatory code walkthroughs. This one still got through and crashed the box. It took about an hour just to SET UP the test to see the box crash, and I had to do the test several times before I tracked down the error. That was test time I could have used doing something USEFUL, if the error had been caught earlier. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 18:44 ` John R. Strohm @ 2003-02-20 19:09 ` Larry Kilgallen 2003-02-20 19:27 ` John R. Strohm 2003-02-20 19:34 ` Hyman Rosen ` (6 subsequent siblings) 7 siblings, 1 reply; 113+ messages in thread From: Larry Kilgallen @ 2003-02-20 19:09 UTC (permalink / raw) In article <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net>, "John R. Strohm" <strohm@airmail.net> writes: > Are you trying to say you DON'T want to catch those "gross errors of > coding - buffer overruns, null pointer accesses, arithmetic overflow, etc."? > > Any one of those "gross errors of coding" can and will crash an embedded > system, or, worse, cause it to fail in a bad way. It was an overflowed > counter that caused a Patriot battery not to engage an incoming Scud, > resulting in the deaths of several U.S. servicemen. Can you provide a citation for that incident ? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:09 ` Larry Kilgallen @ 2003-02-20 19:27 ` John R. Strohm 2003-02-20 19:48 ` Hyman Rosen ` (2 more replies) 0 siblings, 3 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-20 19:27 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:HVDh3osH+3al@eisner.encompasserve.org... > In article <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net>, "John R. Strohm" <strohm@airmail.net> writes: > > > Are you trying to say you DON'T want to catch those "gross errors of > > coding - buffer overruns, null pointer accesses, arithmetic overflow, etc."? > > > > Any one of those "gross errors of coding" can and will crash an embedded > > system, or, worse, cause it to fail in a bad way. It was an overflowed > > counter that caused a Patriot battery not to engage an incoming Scud, > > resulting in the deaths of several U.S. servicemen. > > Can you provide a citation for that incident ? This is from memory, twelve years ago. Operation Desert Storm, near the end of the party, when Saddam Hussein was lobbing Scuds and the U.S. was going crazy trying to find all of his Scud launchers. Incoming Scud detected, Patriot failed to engage, missile hit, destroying (as I recall) a warehouse tent or a barracks tent, killing some twenty troops. Investigation showed that a timer had overflowed. The Patriot system designers assumed that the system would never be operated for more than a few hours at a time, and the timer couldn't overflow in that time. This particular one had been up for several days. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:27 ` John R. Strohm @ 2003-02-20 19:48 ` Hyman Rosen 2003-02-20 21:12 ` John R. Strohm 2003-02-20 21:39 ` Bobby D. Bryant 2003-02-21 8:33 ` Jean-Pierre Rosen 2 siblings, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-20 19:48 UTC (permalink / raw) John R. Strohm wrote: > The Patriot system designers assumed that the system would never > be operated for more than a few hours at a time, and the timer > couldn't overflow in that time. And so is this an illustration of how Ada would have helped, or an illustration of how Ada would not have helped? Had Ada code raised a numeric error at the overflow, would that have caused the missile to engage its target properly? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:48 ` Hyman Rosen @ 2003-02-20 21:12 ` John R. Strohm 0 siblings, 0 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-20 21:12 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1045770511.855483@master.nyc.kbcfp.com... > John R. Strohm wrote: > > The Patriot system designers assumed that the system would never > > be operated for more than a few hours at a time, and the timer > > couldn't overflow in that time. > > And so is this an illustration of how Ada would have helped, > or an illustration of how Ada would not have helped? Had Ada > code raised a numeric error at the overflow, would that have > caused the missile to engage its target properly? Yes, it probably would. The uncaught exception would have taken the battery down, requiring an operator restart, a few days at the very least, before the Scud in question was launched. This in turn would have generated a frantic phone call back to Raytheon in the United States, and quite possibly generated a field patch to eliminate the problem. The workaround would be to reset the system periodically, which opens very narrow windows during which a Scud might not be engaged because the battery was rebooting, as opposed to having the battery down AND NOT KNOWING ABOUT IT. The obvious other step is to move a second battery in, and NOT reboot both of them at the same time. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:27 ` John R. Strohm 2003-02-20 19:48 ` Hyman Rosen @ 2003-02-20 21:39 ` Bobby D. Bryant 2003-02-21 20:36 ` Randy Brukardt 2003-02-21 8:33 ` Jean-Pierre Rosen 2 siblings, 1 reply; 113+ messages in thread From: Bobby D. Bryant @ 2003-02-20 21:39 UTC (permalink / raw) On Thu, 20 Feb 2003 13:27:43 -0600, John R. Strohm wrote: > This is from memory, twelve years ago. > > Operation Desert Storm, near the end of the party, when Saddam Hussein > was lobbing Scuds and the U.S. was going crazy trying to find all of his > Scud launchers. Incoming Scud detected, Patriot failed to engage, > missile hit, destroying (as I recall) a warehouse tent or a barracks > tent, killing some twenty troops. Investigation showed that a timer had > overflowed. The Patriot system designers assumed that the system would > never be operated for more than a few hours at a time, and the timer > couldn't overflow in that time. This particular one had been up for > several days. I thought I remembered that the Patriot *did* intercept the Scud, and knocked it out of the sky but didn't destroy the warhead. Then the warhead fell at a bad-luck spot, killing people who wouldn't have died if it hadn't been intercepted at all. (By a strange coincidence, my memory of the matter is also 12 years old!) -- Bobby Bryant Austin, Texas ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 21:39 ` Bobby D. Bryant @ 2003-02-21 20:36 ` Randy Brukardt 0 siblings, 0 replies; 113+ messages in thread From: Randy Brukardt @ 2003-02-21 20:36 UTC (permalink / raw) Bobby D. Bryant wrote in message ... >On Thu, 20 Feb 2003 13:27:43 -0600, John R. Strohm wrote: > >> This is from memory, twelve years ago. >> >> Operation Desert Storm, near the end of the party, when Saddam Hussein >> was lobbing Scuds and the U.S. was going crazy trying to find all of his >> Scud launchers. Incoming Scud detected, Patriot failed to engage, >> missile hit, destroying (as I recall) a warehouse tent or a barracks >> tent, killing some twenty troops. Investigation showed that a timer had >> overflowed. The Patriot system designers assumed that the system would >> never be operated for more than a few hours at a time, and the timer >> couldn't overflow in that time. This particular one had been up for >> several days. > >I thought I remembered that the Patriot *did* intercept the Scud, and >knocked it out of the sky but didn't destroy the warhead. Then the >warhead fell at a bad-luck spot, killing people who wouldn't have died if >it hadn't been intercepted at all. > >(By a strange coincidence, my memory of the matter is also 12 years old!) I very recently saw a History Channel documentary where they described the incident pretty much as John described it. As I recall, they said that the Patriot missed the Scud entirely because of the error. I do recall some cases in Israel like you describe, not the barracks one. Randy. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:27 ` John R. Strohm 2003-02-20 19:48 ` Hyman Rosen 2003-02-20 21:39 ` Bobby D. Bryant @ 2003-02-21 8:33 ` Jean-Pierre Rosen 2 siblings, 0 replies; 113+ messages in thread From: Jean-Pierre Rosen @ 2003-02-21 8:33 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1692 bytes --] "John R. Strohm" <strohm@airmail.net> a �crit dans le message de news: > This is from memory, twelve years ago. > > Operation Desert Storm, near the end of the party, when Saddam Hussein was > lobbing Scuds and the U.S. was going crazy trying to find all of his Scud > launchers. Incoming Scud detected, Patriot failed to engage, missile hit, > destroying (as I recall) a warehouse tent or a barracks tent, killing some > twenty troops. Investigation showed that a timer had overflowed. The > Patriot system designers assumed that the system would never be operated for > more than a few hours at a time, and the timer couldn't overflow in that > time. This particular one had been up for several days. > My memory is slightly different. I think the problem was that time was represented as a floating point value, not fixed point. As a consequence, the absolute error increased as time went by, leading to more and more imprecise trajectory computations. The engineers were aware of the problem, and hence required a daily reboot of the system, but of course it was a bit hard to understand for a military on-the-field... The main error (IMHO) was to represent time as a floating point, I always argue it must always be represented as a fixed point. It is possible even if your language does not provide predefined fixed points, it's just more work. Now, it can be argued that this error would have been less likely in Ada, since Ada provides fixed point types, and the programmers would have been less tempted of using floats. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 18:44 ` John R. Strohm 2003-02-20 19:09 ` Larry Kilgallen @ 2003-02-20 19:34 ` Hyman Rosen 2003-02-20 19:52 ` Vinzent Hoefler ` (3 more replies) 2003-02-20 21:45 ` Larry Kilgallen ` (5 subsequent siblings) 7 siblings, 4 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-20 19:34 UTC (permalink / raw) John R. Strohm wrote: > So what's your point? My point is that the attitude I often sense on this newsgroup is that using Ada will give you perfect code. (Not in so many words, mind you, but definitely in attitude.) > It was an overflowed counter Assuming that this is even true, would it have been better if the Patriot battery threw an exception? The (first?) Ariane 5 incident was pretty much the same, and that was in Ada. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:34 ` Hyman Rosen @ 2003-02-20 19:52 ` Vinzent Hoefler 2003-02-20 20:14 ` Hyman Rosen 2003-02-20 22:10 ` Peter Flass ` (2 subsequent siblings) 3 siblings, 1 reply; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-20 19:52 UTC (permalink / raw) Hyman Rosen wrote: > Assuming that this is even true, would it have been better > if the Patriot battery threw an exception? In that particular case I'd assume, yes. Some kind of reboot/restart would have helped. > The (first?) Ariane 5 incident was pretty much the same, Not exactly. It was proven that this exception could never occur in normal operation, so assuming a hardware failure if that exception occured was IMO the right decision. > and that was in Ada. Yes. But the code was originally written for another system, the Ariane 4. Using the same code in Ariane 5 with the same assumptions as were valid for Ariane 4 was the failure, not the code itself. It was never written for the system it was used on and then - naturally - failed horribly. Vinzent. -- 71: 69 with two fingers up your ass. -- George Carlin ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:52 ` Vinzent Hoefler @ 2003-02-20 20:14 ` Hyman Rosen 2003-02-20 21:20 ` Vinzent Hoefler 2003-02-21 8:14 ` Ondřej Tučný 0 siblings, 2 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-20 20:14 UTC (permalink / raw) Vinzent Hoefler wrote: > In that particular case I'd assume, yes. Some kind of reboot/restart > would have helped. Which actually sounds just like what's happening in the F-22 case, doesn't it? Things run for a few hours, then have to be rebooted. That's not exactly a hallmark of a reliable system. > It was proven that this exception could never occur in normal operation Sounds pretty much the same to me - a design assumption is violated, and the programming language error handlers start doing stuff that is completely inappropriate to the situation out in the world. > Using the same code in Ariane 5 with the same assumptions as were valid > for Ariane 4 was the failure, not the code itself. And the people who used the Patriot battery for too long (again, assuming this incident is true) caused the failure, not the software. Which is to say, complex systems can have complex failure modes, and the fact that some programming languages will catch simple errors isn't going to help at all with the complex ones. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 20:14 ` Hyman Rosen @ 2003-02-20 21:20 ` Vinzent Hoefler 2003-02-21 8:14 ` Ondřej Tučný 1 sibling, 0 replies; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-20 21:20 UTC (permalink / raw) Hyman Rosen wrote: > Vinzent Hoefler wrote: >> In that particular case I'd assume, yes. Some kind of reboot/restart >> would have helped. > > Which actually sounds just like what's happening in the F-22 case, > doesn't it? To be honest, I don't know what's going on with the F-22. > Things run for a few hours, then have to be rebooted. > That's not exactly a hallmark of a reliable system. I surely agree with that. >> It was proven that this exception could never occur in normal >> operation > > Sounds pretty much the same to me - a design assumption is violated, No, in the Ariane case, it was not an assumption, it was a proof. For the Ariane 4 system. > and the programming language error handlers start doing stuff that is > completely inappropriate to the situation out in the world. It switched over to the backup system. Sounds reasonable when the exception should only occur in case of hardware failures. >> Using the same code in Ariane 5 with the same assumptions as were >> valid for Ariane 4 was the failure, not the code itself. > > And the people who used the Patriot battery for too long (again, > assuming this incident is true) caused the failure, not the software. Well, let's say so: If the manual would have said, reboot the system every two hours, then... ;-) But IMO the Ariane case was different. The system that failed on Ariane 5 was proven to work correct on Ariane 4. The failure was in using the same software without reconsidering the proofs for the new parameters. You wouldn't expect a controller software written for some system in a tank to work the same on a similar system in a - let's say - Volkswagen, where a lot of physics parameter are different, would you? Would you then blame the software engineer who wrote the initial tank-software when your Volkswagen crashes because the software behaves like it is controlling a tank? > Which is to say, complex systems can have complex failure modes, Right. > and the fact that some programming languages will catch simple > errors isn't going to help at all with the complex ones. NAK. One thing is for sure: The ability to get rid of all the small, stupid, simple errors - and even those have very bad consequences a lot of times - helps to keep concentrated on avoiding the complex ones. Vinzent. -- Dope will get you through times of no money better that money will get you through times of no dope. -- Gilbert Shelton ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 20:14 ` Hyman Rosen 2003-02-20 21:20 ` Vinzent Hoefler @ 2003-02-21 8:14 ` Ondřej Tučný 2003-02-21 14:54 ` Hyman Rosen 1 sibling, 1 reply; 113+ messages in thread From: Ondřej Tučný @ 2003-02-21 8:14 UTC (permalink / raw) > And the people who used the Patriot battery for too long (again, assuming > this incident is true) caused the failure, not the software. > > Which is to say, complex systems can have complex failure modes, > and the fact that some programming languages will catch simple > errors isn't going to help at all with the complex ones. Not in all cases. Here a complex failure (failure of a Patriot battery) was originally caused by a simple overflow error. And as someone already pointed out, the complex failure would have never happened if the originating simple error was detected and handled properly. So there is a class of complex failures that are caused by simple errors, and so these complex failures can be eliminated by eliminating (detecting & handling) simple errors. -- Ondďż˝ej Tuďż˝nďż˝ ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 8:14 ` Ondřej Tučný @ 2003-02-21 14:54 ` Hyman Rosen 2003-02-21 15:05 ` Vinzent Hoefler ` (6 more replies) 0 siblings, 7 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 14:54 UTC (permalink / raw) Ondďż˝ej Tuďż˝nďż˝ wrote: > Not in all cases. Here a complex failure (failure of a Patriot battery) > was originally caused by a simple overflow error. And as someone already > pointed out, the complex failure would have never happened if the originating > simple error was detected and handled properly. No. The claim was that the code was written under the assumption that the overflow would not happen. In such a case, the problem would never be "handled properly" since proper handling assumes the belief that the problem can happen. There also seems to be the assumption that the overflow error happens while the battery was just sitting there. It is just as possible that the overflow manifests only during launch, in which case causing a reboot wouldn't be very helpful. I've mentioned this many times before. Language checks such as bounds checking, pointer checking, and overflow checking are fine for testing. But when the application is released, it is better to disable such checks in cases where continued operation is important, because it's more likely that a program which "gets away" with making such an error can keep working, whereas detecting the error will just blow the program away. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:54 ` Hyman Rosen @ 2003-02-21 15:05 ` Vinzent Hoefler 2003-02-21 15:55 ` Preben Randhol ` (5 subsequent siblings) 6 siblings, 0 replies; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-21 15:05 UTC (permalink / raw) Hyman Rosen wrote: > I've mentioned this many times before. Language checks such as > bounds checking, pointer checking, and overflow checking are > fine for testing. But when the application is released, it is > better to disable such checks in cases where continued operation > is important, because it's more likely that a program which > "gets away" with making such an error can keep working, Or just overwrite some more important data so that the device still seems to work but gives wrong results. > whereas detecting the error will just blow the program away. Or the other way around. Depends. The only solution would be an error free program and even that cannot protect you from malfunctioning hardware. Better to catch the exception and turn on the backup system then. Vinzent. -- "Water? Never touch the stuff! Fish fuck in it." -- W. C. Fields ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:54 ` Hyman Rosen 2003-02-21 15:05 ` Vinzent Hoefler @ 2003-02-21 15:55 ` Preben Randhol 2003-02-21 16:45 ` Hyman Rosen 2003-02-21 18:48 ` John R. Strohm ` (4 subsequent siblings) 6 siblings, 1 reply; 113+ messages in thread From: Preben Randhol @ 2003-02-21 15:55 UTC (permalink / raw) Hyman Rosen wrote: > I've mentioned this many times before. Language checks such as > bounds checking, pointer checking, and overflow checking are > fine for testing. But when the application is released, it is So your point is that it is better to use C/C++ which doesn't have these test in the first place? How come there are so many security holes in software then? -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 15:55 ` Preben Randhol @ 2003-02-21 16:45 ` Hyman Rosen 2003-02-21 17:40 ` Preben Randhol 0 siblings, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 16:45 UTC (permalink / raw) Preben Randhol wrote: > So your point is that it is better to use C/C++ which doesn't have these > test in the first place? Oh no, not at all. It's much better for the checks to be there. But you have to be aware of their limitations, and know when you want to disable them. > How come there are so many security holes in software then? My point was that checks should be disabled when it is important for programs to continue operation. Security situations are just the opposite. In that case, you want to abort at any sign of error, perhaps even with timeouts to kill things which run too long, because any such issue can be a sign of attack. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 16:45 ` Hyman Rosen @ 2003-02-21 17:40 ` Preben Randhol 2003-02-21 17:44 ` Preben Randhol 2003-02-21 18:10 ` Hyman Rosen 0 siblings, 2 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-21 17:40 UTC (permalink / raw) Hyman Rosen wrote: > > My point was that checks should be disabled when it is > important for programs to continue operation. Security > situations are just the opposite. In that case, you want > to abort at any sign of error, perhaps even with timeouts > to kill things which run too long, because any such issue > can be a sign of attack. Yes, but in the case you want to have a program running continously it won't help if there are errors in the program which makes the program behave in strange ways. Say a nuclear powerplant. You don't want an untreated integer overflow to cause the rods to be pulled up causing a new nuclear meltdown. You want that the program to catch this error and go into a backup/safe-mode program IMHO. In my simple program I have an outer exception handling. If an exception is caught here the program will try to save the data in an EMERGENCY file before it quits. It will also give the user a notice of the error of course. When the program starts it always checks if there is an EMERGENCY file which if it exists will be loaded and the user will be told that the data is restored and ought to be checked. This works. Another example, when I'm running my experiments (chemistry) in the lab, I'm logging the data from an electrode onto a computer. The logging software worked fine except that I sometimes found that the log had stopped at some random place in the experiment. These experiments can be 10 or more hours and I'm not there during this time. After some checking I found out that what made the program crash was that the some strange feed came from the logger causing the logging program to crash. I changed the program so that in case it got this feed it should simply write -1000 (as this is not a value I would get from my electrode and thus I can remove it later from the log) and then I got the program to continue. I can see in my logs that in some experiments I get this strange error, but after 3 years I still have no idea what causes it, and it is not important as it doesn't influence my experiment now that the logging is working. Note this was not written in Ada, but some language of the logger. So my point is that I don't think that one are more safe turning off all checks in the distributed code. You newer know the side-effects that this will have. It is better to make an outer safty net which can catch the any error and deal with it and notify the user. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 17:40 ` Preben Randhol @ 2003-02-21 17:44 ` Preben Randhol 2003-02-21 18:10 ` Hyman Rosen 1 sibling, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-21 17:44 UTC (permalink / raw) Preben Randhol wrote: > feed came from the logger causing the logging program to crash. I > changed the program so that in case it got this feed it should simply > write -1000 (as this is not a value I would get from my electrode and > thus I can remove it later from the log) and then I got the program to > continue. I can see in my logs that in some experiments I get this By continue I mean that I got it to continue from the right point in the stream. If the program would be able to cope with the erranous feed and write this to the log it would have continued in the wrong place and written gibberish for the rest of the log and this would have been useless. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 17:40 ` Preben Randhol 2003-02-21 17:44 ` Preben Randhol @ 2003-02-21 18:10 ` Hyman Rosen 2003-02-21 18:38 ` Preben Randhol 2003-02-21 18:42 ` Vinzent Hoefler 1 sibling, 2 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 18:10 UTC (permalink / raw) Preben Randhol wrote: > You don't want an untreated integer overflow to cause > the rods to be pulled up causing a new nuclear meltdown. > You want that the program to catch this error and go > into a backup/safe-mode program IMHO. The problem is that we're talking about unanticipated situations, so fallback handling is always going to be iffy. The fallback handling for the Ariane 5 made it blow up, after all. I'm saying that things like buffer overruns and bad memory accesses and to some extent arithmetic overflow can be limited problems - some bit of memory on the stack might get clobbered, but then goes away when the subroutine returns, for example. This means that even though the program has acted erroneously in programming language terms, it is still working properly from an outside point of view - the toaster is still heating the bread. On the other hand, noticing the error will almost certainly abort the operation, and since we're talking about unanticipated errors, things may just come to a halt. Whether this is desirable depends on the application. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 18:10 ` Hyman Rosen @ 2003-02-21 18:38 ` Preben Randhol 2003-02-21 18:40 ` Preben Randhol 2003-02-21 18:52 ` Hyman Rosen 2003-02-21 18:42 ` Vinzent Hoefler 1 sibling, 2 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-21 18:38 UTC (permalink / raw) Hyman Rosen wrote: > Preben Randhol wrote: >> You don't want an untreated integer overflow to cause > > the rods to be pulled up causing a new nuclear meltdown. > > You want that the program to catch this error and go > > into a backup/safe-mode program IMHO. > > The problem is that we're talking about unanticipated > situations, so fallback handling is always going to be > iffy. The fallback handling for the Ariane 5 made it > blow up, after all. Which was the correct thing to do! You don't want the rocket to accelerate down and hit your head do you? > I'm saying that things like buffer overruns and bad > memory accesses and to some extent arithmetic overflow > can be limited problems - some bit of memory on the > stack might get clobbered, but then goes away when the > subroutine returns, for example. This means that even > though the program has acted erroneously in programming > language terms, it is still working properly from an > outside point of view - the toaster is still heating > the bread. Heating it until it starts to burn? I guess one see buffer overruns as a limited problem to the computer that was broken into? Well it happened at the university here and 25000 had to change passwords in some hours. > On the other hand, noticing the error will almost > certainly abort the operation, and since we're talking > about unanticipated errors, things may just come to a > halt. Whether this is desirable depends on the application. Well that's why you have: "anticipated the unexpected!" -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 18:38 ` Preben Randhol @ 2003-02-21 18:40 ` Preben Randhol 2003-02-21 18:52 ` Hyman Rosen 1 sibling, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-21 18:40 UTC (permalink / raw) Preben Randhol wrote: > > Well that's why you have: "anticipated the unexpected!" anticipate the unexpected! those pesky tyops. :-( -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 18:38 ` Preben Randhol 2003-02-21 18:40 ` Preben Randhol @ 2003-02-21 18:52 ` Hyman Rosen 2003-02-21 19:24 ` Vinzent Hoefler 1 sibling, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 18:52 UTC (permalink / raw) Preben Randhol wrote: > Which was the correct thing to do! I believe that if the error had gone undetected instead of handled, the rocket would have flown properly. > Heating it until it starts to burn? With toasters, that's actually a fine mode of operation. You begin to smell the toast overheating, and you go and manually release it. A little scraping if necessary, and then you munch away. > I guess one see buffer overruns as a limited problem to > the computer that was broken into? I've already said that things like this are situational. If you're worried about security then you have to deal with these kinds of problems differently and then the most stringent runtime checks are appropriate because you would rather abort than be compromised. But no one is sending deliberately malformed strings to a toaster or a rocket. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 18:52 ` Hyman Rosen @ 2003-02-21 19:24 ` Vinzent Hoefler 2003-02-21 19:57 ` Hyman Rosen 2003-02-21 20:55 ` Randy Brukardt 0 siblings, 2 replies; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-21 19:24 UTC (permalink / raw) Hyman Rosen wrote: > Preben Randhol wrote: [Ariane 5] > I believe that if the error had gone undetected instead > of handled, the rocket would have flown properly. No. I am not sure about that. Maybe... >> Heating it until it starts to burn? > > With toasters, that's actually a fine mode of operation. Are you serious? > You begin to smell the toast overheating, and you go and > manually release it. A little scraping if necessary, and > then you munch away. Or standing with a fire extinguisher in the completely burned down kitchen. > I've already said that things like this are situational. ACK. But even on one single system you cannot say if a better approach would be ignoring or eventually handling the error. > But no one is sending deliberately malformed strings to a toaster > or a rocket. For the rocket : Malfunctioning sensor hardware might act like one. For the toaster: Not yet. Vinzent. -- Q: How many right-to-lifers does it take to change a light bulb? A: Two. One to screw it in and one to say that light started when the screwing began. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 19:24 ` Vinzent Hoefler @ 2003-02-21 19:57 ` Hyman Rosen 2003-02-21 20:37 ` Vinzent Hoefler 2003-02-21 20:55 ` Randy Brukardt 1 sibling, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 19:57 UTC (permalink / raw) Vinzent Hoefler wrote: > ACK. But even on one single system you cannot say if a better approach > would be ignoring or eventually handling the error. Pretty much by definition, no one expects these kinds of errors, since they represent errors in the logic of the code; you would just fix the logic, not add error handlers. So the only thing you might have is some outer catch-all handler which when invoked knows only that a disaster has happened. So what do you do? Assume a bounded software error and reboot, hoping the problem will go away? Assume hardware failure, and go to your backups? Shut down? Maybe it's just that someone miscounted the number of letters in 'September' and has managed to overrun an array by one character, and if you left it alone, the program would keep going just fine. There's no one right answer, but I'm firmly convinced that ignoring errors is in the set of reasonable actions. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 19:57 ` Hyman Rosen @ 2003-02-21 20:37 ` Vinzent Hoefler 0 siblings, 0 replies; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-21 20:37 UTC (permalink / raw) Hyman Rosen wrote: > Vinzent Hoefler wrote: >> ACK. But even on one single system you cannot say if a better >> approach would be ignoring or eventually handling the error. > > Pretty much by definition, no one expects these kinds > of errors, Well, I always expect errors. ;) > since they represent errors in the logic of > the code; you would just fix the logic, not add error > handlers. ACK. But to do that you should first know there is an error. > So the only thing you might have is some outer catch-all > handler which when invoked knows only that a disaster > has happened. So what do you do? Assume a bounded software > error and reboot, hoping the problem will go away? Assume > hardware failure, and go to your backups? Shut down? Such a "global failure" action highly depends on the system you are controlling. In the case of a nuclear plant a clean shutdown is probably the safest you can do, on a mobile phone simply restarting it could be a more appropiate decision. I think a significant part of the embedded systems out there currently use the approach to restart the system by using some watchdog timers or catch-all handlers and they just run fine with that. Needless to say, that such a decision might be the wrong one for the one particular "unthinkable" error. > Maybe it's just that someone miscounted the number of > letters in 'September' and has managed to overrun an > array by one character, and if you left it alone, the > program would keep going just fine. Maybe it overwrote some other parameter and now will do weird and possibly dangerous things. As I said, you never know until it actually happens. > There's no one right answer, but I'm firmly convinced > that ignoring errors is in the set of reasonable actions. Sometimes, yes. At least in Ada you always have the option to turn off all the checks if you really want to do so. But I think, as soon as such error is detected it should be fixed. So IMO it should be a strong requirement to either avoid the error completely by doing it correct the first time or detect such error at runtime in whatever system we are talking about. So, even in the case of letting the program go on after detecting such a violation, at least having a chance to log it and try to recover the system without a "real" dedicated error handler then *could* be fine. BTW, especially in the case of buffer overruns the system will crash anyway most of the times, because of a corrupted stack. Detecting the error before it screws everything up just makes the crash look more clean. ;) Vinzent. -- "I own my own body, but I share" ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 19:24 ` Vinzent Hoefler 2003-02-21 19:57 ` Hyman Rosen @ 2003-02-21 20:55 ` Randy Brukardt 1 sibling, 0 replies; 113+ messages in thread From: Randy Brukardt @ 2003-02-21 20:55 UTC (permalink / raw) Hyman Rosen wrote: > But no one is sending deliberately malformed strings to a toaster > or a rocket. Yet. You can bet if there is a way to do it, it will happen. Security is something you do all the time, on every program, because anything can be the vector of an attack. "It's only Notepad" or "It's only a toaster" doesn't cut it. Randy. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 18:10 ` Hyman Rosen 2003-02-21 18:38 ` Preben Randhol @ 2003-02-21 18:42 ` Vinzent Hoefler 1 sibling, 0 replies; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-21 18:42 UTC (permalink / raw) Hyman Rosen wrote: > The problem is that we're talking about unanticipated > situations, so fallback handling is always going to be > iffy. The fallback handling for the Ariane 5 made it > blow up, after all. Mmh. Yes. As I said, the code in question was not wrong, it was just used in the wrong system. Would it have happened on Ariane 4, the fallback would have been the perfectly right decision. > I'm saying that things like buffer overruns and bad > memory accesses and to some extent arithmetic overflow > can be limited problems *can be*, yes. My experience says, most of the times they are not worse or better than any other kind of error. Real life example: The calculation for a list of machine parameters caused on overflow. It went through undetected and everything was fine just until the last set of parameter should have been activated. That did not happen, because it was not accessed anymore, it was out of the defined bounds. In the end this rendered the whole process useless. Catching the error beforehand would have caused the same uselessness just in another (time- and moneysaving) degree. The chance of detecting and fixing it earlier also would have been higher. I guess, we can both bring one example after the other, where on approach is better than the other. In the end, we both probably agree, such errors should not happen at all. > On the other hand, noticing the error will almost > certainly abort the operation, and since we're talking > about unanticipated errors, things may just come to a > halt. Or the big fat global exception handler just initiates a complete reboot or tries to get the thing into a safe state. Whatever you may do, it *can* under some circumstances be the wrong decision. > Whether this is desirable depends on the application. Yes. And IMO one of the main problem of deciding what might be better is: You never know until it actually happens. So I think, trying to minimize the number of possible errors is a good start. Vinzent. -- Nuke the gay, unborn, baby whales for Jesus. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:54 ` Hyman Rosen 2003-02-21 15:05 ` Vinzent Hoefler 2003-02-21 15:55 ` Preben Randhol @ 2003-02-21 18:48 ` John R. Strohm 2003-02-21 20:22 ` Richard Riehle ` (3 subsequent siblings) 6 siblings, 0 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-21 18:48 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1726 bytes --] "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1045839283.86671@master.nyc.kbcfp.com... > Ond�ej Tu�n� wrote: > > Not in all cases. Here a complex failure (failure of a Patriot battery) > > was originally caused by a simple overflow error. And as someone already > > pointed out, the complex failure would have never happened if the originating > > simple error was detected and handled properly. > > No. The claim was that the code was written under the assumption > that the overflow would not happen. In such a case, the problem > would never be "handled properly" since proper handling assumes > the belief that the problem can happen. > > There also seems to be the assumption that the overflow error > happens while the battery was just sitting there. It is just > as possible that the overflow manifests only during launch, in > which case causing a reboot wouldn't be very helpful. > > I've mentioned this many times before. Language checks such as > bounds checking, pointer checking, and overflow checking are > fine for testing. But when the application is released, it is > better to disable such checks in cases where continued operation > is important, because it's more likely that a program which > "gets away" with making such an error can keep working, whereas > detecting the error will just blow the program away. One of the luminaries of Computer Science answered that one many years ago. He compared that strategy (specifically with array bounds checking) to wearing a life jacket while playing about inside the sheltered harbor, but discarding the life jacket upon venturing into the open ocean. I think it was Tony Hoare, but it might have been Edsger Dijkstra or Nicklaus Wirth. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:54 ` Hyman Rosen ` (2 preceding siblings ...) 2003-02-21 18:48 ` John R. Strohm @ 2003-02-21 20:22 ` Richard Riehle 2003-02-21 20:51 ` Randy Brukardt ` (2 subsequent siblings) 6 siblings, 0 replies; 113+ messages in thread From: Richard Riehle @ 2003-02-21 20:22 UTC (permalink / raw) Hyman Rosen wrote: > I've mentioned this many times before. Language checks such as > bounds checking, pointer checking, and overflow checking are > fine for testing. But when the application is released, it is > better to disable such checks in cases where continued operation > is important, because it's more likely that a program which > "gets away" with making such an error can keep working, whereas > detecting the error will just blow the program away. HmmmMMMmmmmm. Sounds as if you just invented SPARK. Richard Riehle ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:54 ` Hyman Rosen ` (3 preceding siblings ...) 2003-02-21 20:22 ` Richard Riehle @ 2003-02-21 20:51 ` Randy Brukardt 2003-02-21 21:29 ` Hyman Rosen 2003-02-22 11:06 ` Preben Randhol [not found] ` <iqeli-c2d.ln1@beastie.ix.netcom.com> 2003-02-23 19:19 ` Berend de Boer 6 siblings, 2 replies; 113+ messages in thread From: Randy Brukardt @ 2003-02-21 20:51 UTC (permalink / raw) Hyman Rosen wrote in message <1045839283.86671@master.nyc.kbcfp.com>... >I've mentioned this many times before. Language checks such as >bounds checking, pointer checking, and overflow checking are >fine for testing. But when the application is released, it is >better to disable such checks in cases where continued operation >is important, because it's more likely that a program which >"gets away" with making such an error can keep working, whereas >detecting the error will just blow the program away. Usually it is better to make the checks and prevent the "wrong answer". This is, after all, the cause of some many of the security holes on the Internet. The web server for AdaIC is written in Ada. I've left all of the checking on, and provide a global exception handler for each worker thread. Thus, the worst that can happen for a mistaken check is the currently processed operation to be abandoned (the server sends an internal error response to the client). That prevents all sort of security holes from buffer overflows and the like. It of course does not prevent all errors, but it allowed me to focus on blocking the common security problems that are algorithmic in nature, like traversal errors. Although the code has had a variety of buffer overflow and other bugs cause individual operations to fail, the server has continued to run and process other operations correctly for the entire 18 months. (And, all failures have been logged so that the cause can be tracked down easily). This has allowed the focus to be on the web site's contents, not on keeping the server running. There probably are cases where it is better to run with checks off. (We always did that with Janus/Ada for MS-DOS, just to keep the compiler size managable. That's not an issue on Windows.) But I would generally prefer to err on the side of leaving checks on unless it is necessary to do otherwise. Randy. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 20:51 ` Randy Brukardt @ 2003-02-21 21:29 ` Hyman Rosen 2003-02-21 21:44 ` Vinzent Hoefler 2003-02-22 11:06 ` Preben Randhol 1 sibling, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 21:29 UTC (permalink / raw) Randy Brukardt wrote: > the cause of some many of the security holes As I keep saying, the security case is one in which you would rather halt altogether than allow errors to occur. But not everything warrants that approach. Some things, like bombs and rockets, should just keep going, because there's no good alternative. In that case, detecting the error is probably not as good as ignoring it. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:29 ` Hyman Rosen @ 2003-02-21 21:44 ` Vinzent Hoefler 2003-02-23 5:05 ` Hyman Rosen 0 siblings, 1 reply; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-21 21:44 UTC (permalink / raw) Hyman Rosen wrote: > Some things, like bombs and rockets, should just > keep going, because there's no good alternative. Really? |exception | when others => | Self_Destroy; ;-) > In that case, detecting the error is probably not > as good as ignoring it. Well, still better it simply falls down doing nothing more harmful than to bury some sheep under it, than to detonate over the wrong (friendly) target. Vinzent. -- "He could be a poster child for retroactive birth control." ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:44 ` Vinzent Hoefler @ 2003-02-23 5:05 ` Hyman Rosen 2003-02-24 16:29 ` Vinzent Hoefler 0 siblings, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-23 5:05 UTC (permalink / raw) Vinzent Hoefler wrote: > Well, still better it simply falls down doing nothing more harmful than > to bury some sheep under it, than to detonate over the wrong (friendly) > target. I meant that there's no time or ability to restart, so it may as well keep on going instead of shut down. Self-destruct is usually handled by the ground controllers anyway. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-23 5:05 ` Hyman Rosen @ 2003-02-24 16:29 ` Vinzent Hoefler 0 siblings, 0 replies; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-24 16:29 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote: >Vinzent Hoefler wrote: >> Well, still better it simply falls down doing nothing more harmful than >> to bury some sheep under it, than to detonate over the wrong (friendly) >> target. > >I meant that there's no time or ability to restart, so it may as well >keep on going instead of shut down. Depending on what the error actually does, both things can be dangerous. >Self-destruct is usually handled >by the ground controllers anyway. Hopefully it is running on a secondary system, otherwise the off-by-one error in the guidance control system might disable this feature suddenly. :-> Vinzent. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 20:51 ` Randy Brukardt 2003-02-21 21:29 ` Hyman Rosen @ 2003-02-22 11:06 ` Preben Randhol 2003-02-23 22:04 ` tmoran 2003-02-24 20:15 ` Randy Brukardt 1 sibling, 2 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-22 11:06 UTC (permalink / raw) Randy Brukardt wrote: > The web server for AdaIC is written in Ada. I've left all of the RRS Ada HTTP Server right? > Although the code has had a variety of buffer overflow and other bugs Buffer overflow? How? -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 11:06 ` Preben Randhol @ 2003-02-23 22:04 ` tmoran 2003-02-24 9:32 ` Preben Randhol 2003-02-24 20:15 ` Randy Brukardt 1 sibling, 1 reply; 113+ messages in thread From: tmoran @ 2003-02-23 22:04 UTC (permalink / raw) > > Although the code has had a variety of buffer overflow and other bugs > > Buffer overflow? How? Randy may be refering to an off-by-one buffer size error in some code I wrote passing a buffer to a C (Windows) routine. :( ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-23 22:04 ` tmoran @ 2003-02-24 9:32 ` Preben Randhol 2003-03-02 2:37 ` AG 0 siblings, 1 reply; 113+ messages in thread From: Preben Randhol @ 2003-02-24 9:32 UTC (permalink / raw) tmoran@acm.org wrote: >> > Although the code has had a variety of buffer overflow and other bugs >> >> Buffer overflow? How? > Randy may be refering to an off-by-one buffer size error in some code > I wrote passing a buffer to a C (Windows) routine. :( Ok so the buffer overflow happend in C. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-24 9:32 ` Preben Randhol @ 2003-03-02 2:37 ` AG 2003-03-01 13:46 ` Preben Randhol 0 siblings, 1 reply; 113+ messages in thread From: AG @ 2003-03-02 2:37 UTC (permalink / raw) "Preben Randhol" <randhol+news@pvv.org> wrote in message > Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- > "Violence is the last refuge of the incompetent", Isaac Asimov "Armed society is polite society", Robert Heinlein [from "Beyond this Horizon"] I think we are in a definite agreement there - pass the guns please :) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-02 2:37 ` AG @ 2003-03-01 13:46 ` Preben Randhol 2003-03-03 0:57 ` AG 0 siblings, 1 reply; 113+ messages in thread From: Preben Randhol @ 2003-03-01 13:46 UTC (permalink / raw) AG wrote: > > "Preben Randhol" <randhol+news@pvv.org> wrote in message > > >> Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- >> "Violence is the last refuge of the incompetent", Isaac Asimov > > > "Armed society is polite society", Robert Heinlein [from "Beyond this > Horizon"] > > I think we are in a definite agreement there - pass the guns please :) > No, we are definitely not. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-01 13:46 ` Preben Randhol @ 2003-03-03 0:57 ` AG 2003-03-02 12:40 ` Preben Randhol 0 siblings, 1 reply; 113+ messages in thread From: AG @ 2003-03-03 0:57 UTC (permalink / raw) "Preben Randhol" <randhol+news@pvv.org> wrote in message news:slrnb61eac.l7.randhol+news@kiuk0152.chembio.ntnu.no... > AG wrote: > > > > "Preben Randhol" <randhol+news@pvv.org> wrote in message > > > > > >> Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- > >> "Violence is the last refuge of the incompetent", Isaac Asimov > > > > > > "Armed society is polite society", Robert Heinlein [from "Beyond this > > Horizon"] > > > > I think we are in a definite agreement there - pass the guns please :) > > > > No, we are definitely not. Why? The whole point of Heinlein's statement was that having citizens armed means it's a little bit harder for violent types do go violent. Which seems to jive-in nicely with your signature ... > > -- > Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- > "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-03 0:57 ` AG @ 2003-03-02 12:40 ` Preben Randhol 2003-03-02 16:52 ` John R. Strohm 0 siblings, 1 reply; 113+ messages in thread From: Preben Randhol @ 2003-03-02 12:40 UTC (permalink / raw) AG wrote: > Why? > > The whole point of Heinlein's statement was > that having citizens armed means it's a little > bit harder for violent types do go violent. Is this true in USA with 11000 gun related killings per year (if I remember correctly)? > Which seems to jive-in nicely with your signature ... You apparently haven't grasped it then :-) -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-02 12:40 ` Preben Randhol @ 2003-03-02 16:52 ` John R. Strohm 2003-03-03 0:19 ` Georg Bauhaus 2003-03-03 8:01 ` Preben Randhol 0 siblings, 2 replies; 113+ messages in thread From: John R. Strohm @ 2003-03-02 16:52 UTC (permalink / raw) "Preben Randhol" <randhol+news@pvv.org> wrote in message news:slrnb63urv.1jh.randhol+news@kiuk0152.chembio.ntnu.no... > AG wrote: > > Why? > > > > The whole point of Heinlein's statement was > > that having citizens armed means it's a little > > bit harder for violent types do go violent. > > Is this true in USA with 11000 gun related killings per year (if I > remember correctly)? > > > Which seems to jive-in nicely with your signature ... > > You apparently haven't grasped it then :-) Since you have decided to pick the fight... It perhaps matches more closely with the experience in Australia and the United Kingdom. Both nations enacted total bans on private ownership of firearms. Both nations then watched their firearm crime rates, and their overall violent crime rates, skyrocket. They have NO clue why this happened. Meanwhile, some years back, the small town of Kennesaw, in the state of Georgia, in the United States of America, passed a local ordinance that REQUIRED every head-of-household to own a firearm. While the ordinance was apparently not taken all that seriously by the locals, Kennesaw nevertheless saw their crime rate go to zero overnight. The likely explanation for these observations is simple enough. When a cretin decides to commit an antisocial act against a law-abiding citizen, the cretin must evaluate the likelihood that his target will be armed. The calculus is quite simple in those places that have outlawed personal protection weapons: a law-abiding citizen in those places is known a priori to be disarmed. In Kennesaw, the calculus was quite different, a law-abiding citizen in Kennesaw was now known a priori to be armed and dangerous. (The most dangerous armed person is one who does not really know what he is doing: he is far more likely to shoot to kill. An armed, prepared citizen knows that the mere presentation of the business end of a weapon is sufficient in the vast majority of cases to dissuade a cretin.) It seems that the cretins who were responsible for the local crime problems decided that the odds had just shifted against them. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-02 16:52 ` John R. Strohm @ 2003-03-03 0:19 ` Georg Bauhaus 2003-03-03 3:03 ` John R. Strohm 2003-03-04 12:11 ` Faust 2003-03-03 8:01 ` Preben Randhol 1 sibling, 2 replies; 113+ messages in thread From: Georg Bauhaus @ 2003-03-03 0:19 UTC (permalink / raw) John R. Strohm <strohm@airmail.net> wrote: : Meanwhile, some years back, the small town of Kennesaw, it is puzzling to see that people who professionally deal with logic (programmers) start falling for any particular evidence supporting something, despite its logical incompleteness, as long as it is in favour of their views. On either side. - Of course, one has to ask what kind of place Kennesaw is. One has to ask how high the percentage of social cohesion and homogeneity in a town like this is. From what I hear there is no need to force people to get a gun in parts of Los Angeles, however it is not particularly silent there. - One has to ask why it is--again--not seen that the Kennesaw success might as well have had to do with the "Hawthorne experiment" effect. It works in part because everyone gets involved, the emphasis being on getting involved, not on being cretin or not, and not on weapons. - One has to ask whether an average sample town is free of Montagus and Capulets. And for practical purposes the average has to be the modus of towns of this kind, because otherwise it is just one sample that seems to have displayed some characteristics that cannot really be predicted to occur elsewhere, given the same requirements. - One has to assume(!) that there are no cretins in each town to wich this model can be ported, if it can, see above. For otherwise people couldn't trust each other; I guess you haven't missed the "trust discussion" in the USA. Imagine: Every step you make you will have one hand near your weapon. - There is more to add, as to every one-factor-theory. - So, ... - Facing community issues, one has to remember, how, for example, men and women of (protestant christian) god, with no weapons and a very homogeous social life deal with people in their community who chose to obey differing moral rules. Rules which, as moral rules, are o.K. even for the conservative U.S. citizen but not for the chiefs in the community. For (an extreme) example, consider the Hutterer communities: At best, the "disobedient" will have to leave, banned (without any possesions). (Not exactly "fault tolerant social software", these rules.) As far as drawing conclusions from this example is concerned, same thing as in the Kennesaw case: interesting but not near general enough. Certainly "Bowling for Columbine" is biased, but can you explain, using Kennesaw theory, why there are less killings per person in Canada, and why they don't lock their doors in Toronto, apparently? It is almost the same as saying, Ada is The Right Programming Language because in a particular project, some goal had been achieved. Even in a largely complexity-reduced field such as programming, a one factor theory is just not enough, it is detrimental. And, finally, and most importantly, murder doesn't require the murderer to have a gun, and gun owners have been murdered more than once. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-03 0:19 ` Georg Bauhaus @ 2003-03-03 3:03 ` John R. Strohm 2003-03-04 12:11 ` Faust 1 sibling, 0 replies; 113+ messages in thread From: John R. Strohm @ 2003-03-03 3:03 UTC (permalink / raw) "Georg Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:b3u73c$7uo$1@a1-hrz.uni-duisburg.de... > John R. Strohm <strohm@airmail.net> wrote: > : Meanwhile, some years back, the small town of Kennesaw, > > it is puzzling to see that people who professionally deal with > logic (programmers) start falling for any particular evidence supporting > something, despite its logical incompleteness, as long as it is in favour > of their views. On either side. I find it amazing that an individual who allegedly deals professionally with logic should apparently be so totally unfamiliar with the concept of "experiment". I will simplify it for you. The hypothesis is that legal availability of firearms correlates positively with violent crime rate. This suggests that curtailing the legal availability of firearms should, if the hypothesis is correct, reduce the violent crime rate. A simple analysis would reveal a questionable assumption, namely, that an individual who is predisposed to commit a violent crime might nevertheless obey a law that denied him the right to own a firearm, but we will neglect that particular contradiction for the purpose of this analysis. An experimentalist immediately realizes that it is easy to test the hypothesis by curtailing personal firearm ownership and seeing whether the violent crime rate goes down, as the hypothesis would predict. This, Herr Bauhaus, is called "conducting an experiment." We first observe that this experiment has been conducted in varying degrees in quite a number of places in the United States. The results of those experiments have been UNIVERSALLY negative: in EVERY venue in which it has been tried, the result has been an INCREASE in the violent crime rate. It is a trivial exercise with an almanac to verify the statistical truth that those locales in the United States with the toughest local gun control laws also have the HIGHEST violent crime rates. We further observe, Herr Bauhaus, that similar experiments were conducted, on much larger scales, national rather than local or regional, in Australia and the United Kingdom. Both of those trials gave the same negative results: both nations experienced a dramatic INCREASE in their violent crime rates. This evidence, by itself, should be enough to indicate that the proposed hypothesis is, at best, faulty. However, another trial was performed, at Kennesaw. If the hypothesis was true, then REQUIRING all citizens of Kennesaw to own firearms SHOULD have resulted in an immediate and statistically-significant INCREASE in the violent crime rate. However, when the experiment was tried, It Didn't Work Out That Way. Kennesaw instead saw an immediate, almost heart-stopping, decrease in the local crime rate. It should be noted in passing that Kennesaw is not much different from other small towns in that part of Georgia. Before the ordinance was passed, they all had pretty comparable demographics, populations, institutions, and crime rates. After the ordinance passed, only Kennesaw saw the dramatic reduction in crime. The first-order interpretation of the data would tend to suggest that, in this CONTROLLED study (the other towns being, of course, the control group), the ordinance made a difference and the result emphatically did not support the hypothesis, but rather argued forcefully that the hypothesis was false. > - Of course, one has to ask what kind of place Kennesaw is. > One has to ask how high the percentage of social cohesion > and homogeneity in a town like this is. From what I hear there > is no need to force people to get a gun in parts of Los Angeles, > however it is not particularly silent there. Actually, it is quite difficult. California requires a three WEEK waiting period between purchase and delivery. This caused significant difficulty during the civil unrest after the Rodney King verdict: local shopkeepers who realized there was trouble brewing, and who wished to purchase weapons to deter rioters and looters from destroying their businesses were prevented from doing so. Those few shopkeepers who had a more jaundiced view of the local animals, who already owned firearms, had no difficulty persuading the looters to go elsewhere: it is amazing how effective the mere sight of a weapon is in deterring a cretin. > - One has to ask why it is--again--not seen that the Kennesaw > success might as well have had to do with the "Hawthorne > experiment" effect. It works in part because everyone gets > involved, the emphasis being on getting involved, not on being > cretin or not, and not on weapons. The Hawthorne Effect is that both positive and negative changes in the control variable produce the same kind of change in the controlled variable. For a Hawthorne Effect hypothesis to be supportable in this area, BOTH increasing AND curtailing the legal availability of firearms must have had the SAME qualitative effect, that of either increasing or decreasing the crime rate. A quick review of the experimental data, however, shows that this is most emphatically not the case, and so the Hawthorne Effect hypothesis must be rejected. > - One has to ask whether an average sample town is free > of Montagus and Capulets. And for practical purposes the > average has to be the modus of towns of this kind, because > otherwise it is just one sample that seems to have displayed > some characteristics that cannot really be predicted to occur > elsewhere, given the same requirements. Montague-Capulet feuds have historically not been common in the United States. While it is true that Kennesaw is a small town of a certain character, there are MANY such small towns of similar character in the United States. It is, as I have discussed above, also the case that Kennesaw is not by any stretch of the imagination the only data point under consideration. > - One has to assume(!) that there are no cretins in each town > to wich this model can be ported, if it can, see above. For > otherwise people couldn't trust each other; I guess you haven't > missed the "trust discussion" in the USA. Imagine: Every step > you make you will have one hand near your weapon. - There is > more to add, as to every one-factor-theory. - So, ... > > - Facing community issues, one has to remember, how, for example, > men and women of (protestant christian) god, with no weapons > and a very homogeous social life > deal with people in their community who chose to obey differing > moral rules. Rules which, as moral rules, are o.K. even for the > conservative U.S. citizen but not for the chiefs in the community. > For (an extreme) example, consider the Hutterer communities: > At best, the "disobedient" will have to leave, banned (without any > possesions). (Not exactly "fault tolerant social software", these > rules.) This is true in those limited (!) cases. Such communities are VERY rare in the United States, far more so than towns like Kennesaw. > As far as drawing conclusions from this example is concerned, > same thing as in the Kennesaw case: interesting but not near > general enough. > > Certainly "Bowling for Columbine" is biased, but can you > explain, using Kennesaw theory, why there are less killings > per person in Canada, and why they don't lock their doors in > Toronto, apparently? No, I can't. Nor am I crazy enough to assume without testing that the examples of what works in Canada, or specifically in Toronto, are likely to be applicable elsewhere. That is the key point. It is necessary to test the hypotheses in the area of interest. The tests that have actually been performed, in many parts of the United States, and in Australia and the United Kingdom, seem to argue strongly that the Kennesaw model *IS* applicable. As an extreme example, it is for all practical purposes unlawful for a citizen of the District of Columbia, the capital of the United States, to possess a firearm. It is also the case that the District of Columbia has the highest murder rate in the United States, almost all committed with firearms. It is a matter of fact that the District police department is totally and completely outgunned by the local drug gangs, and the District chief of police admitted it on television several years ago, during a highly lethal "turf war" between two rival gangs. > It is almost the same as saying, Ada is The Right Programming > Language because in a particular project, some goal had > been achieved. Even in a largely complexity-reduced field > such as programming, a one factor theory is just not enough, > it is detrimental. Not proven. A one-factor hypothesis that CONSISTENTLY gives the same result, when everything else is held constant, is a strong indicator of ground truth. A one-factor hypothesis that continues to give consistent results when other variables are varied, or that can be calibrated for other variables, is even stronger. A one-factor hypothesis must fail to give consistent results in these cases before multiple-factor hypotheses can reasonably be considered. (Occam's Razor is, after all, required knowledge for programmers.) > And, finally, and most importantly, murder doesn't require the > murderer to have a gun, and gun owners have been murdered more > than once. "Statistical significance" is the important concept here. In Japan, gun-related crime had been almost unknown. There was and is still murder, but it mostly used other weapons. It is also significant to note that gun possession is unlawful in Japan, but gun-related crime in Japan is increasing steadily. The fundamental rule is this: One experimental result is worth a thousand theories. When theory and experimental result conflict, the experimental result must win. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-03 0:19 ` Georg Bauhaus 2003-03-03 3:03 ` John R. Strohm @ 2003-03-04 12:11 ` Faust 1 sibling, 0 replies; 113+ messages in thread From: Faust @ 2003-03-04 12:11 UTC (permalink / raw) Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes: > explain, using Kennesaw theory, why there are less killings > per person in Canada, and why they don't lock their doors in > Toronto, apparently? Or in large parts of Sydney. My front door and french windows lie open all day. I close the front door at night. But leave the french windows open most nights. ( I close them in winter ) The back door and all the windows are left open 24 hours a day , regardless of whether or not there is someone at home. However, I do live in a rather low crime part of Sydney. -- natsu-gusa ya / tsuwamono-domo-ga / yume no ato summer grasses / strong ones / dreams site Summer grasses, All that remains Of soldier's dreams (Basho trans. Stryk) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-03-02 16:52 ` John R. Strohm 2003-03-03 0:19 ` Georg Bauhaus @ 2003-03-03 8:01 ` Preben Randhol 1 sibling, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-03-03 8:01 UTC (permalink / raw) John R. Strohm wrote: > > Since you have decided to pick the fight... Huh? I didn't pick any fight. I'm not interested in debating this on the Ada list. Preben PS: I changed the signature again :-) -- This is Ada95 land. On quiet nights you can hear C programmers debug. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 11:06 ` Preben Randhol 2003-02-23 22:04 ` tmoran @ 2003-02-24 20:15 ` Randy Brukardt 2003-02-25 10:00 ` Preben Randhol 1 sibling, 1 reply; 113+ messages in thread From: Randy Brukardt @ 2003-02-24 20:15 UTC (permalink / raw) Preben Randhol wrote in message ... >Randy Brukardt wrote: >> The web server for AdaIC is written in Ada. I've left all of the > >RRS Ada HTTP Server right? Right. It was based Tom Moran's Simple Server, but of course it was improved a lot. >> Although the code has had a variety of buffer overflow and other bugs > >Buffer overflow? How? In order to avoid dynamic allocation of commands, I put the parsed commands into a record type with a bunch of statically bounded strings. These have to be carefully handled for overflow, and there were a couple of obscure cases where I got it wrong. Of course, nothing bad happened, I just got a logged Constraint_Error and the command was aborted. (Since the problems all came from people trying to break in, I wasn't even particularly upset that they weren't served...) Randy. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-24 20:15 ` Randy Brukardt @ 2003-02-25 10:00 ` Preben Randhol 2003-02-26 1:10 ` Randy Brukardt 2003-02-26 18:49 ` Stephen Leake 0 siblings, 2 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-25 10:00 UTC (permalink / raw) Randy Brukardt wrote: > In order to avoid dynamic allocation of commands, I put the parsed > commands into a record type with a bunch of statically bounded strings. > These have to be carefully handled for overflow, and there were a couple > of obscure cases where I got it wrong. Of course, nothing bad happened, > I just got a logged Constraint_Error and the command was aborted. (Since > the problems all came from people trying to break in, I wasn't even > particularly upset that they weren't served...) So in reality it wasn't a buffer overflow as Ada caught it, while if it had been in C you would have had a buffer overflow and possibly people breaking in. Did I understand it correctly? -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-25 10:00 ` Preben Randhol @ 2003-02-26 1:10 ` Randy Brukardt 2003-02-26 18:49 ` Stephen Leake 1 sibling, 0 replies; 113+ messages in thread From: Randy Brukardt @ 2003-02-26 1:10 UTC (permalink / raw) Preben Randhol wrote in message ... >Randy Brukardt wrote: >> In order to avoid dynamic allocation of commands, I put the parsed >> commands into a record type with a bunch of statically bounded strings. >> These have to be carefully handled for overflow, and there were a couple >> of obscure cases where I got it wrong. Of course, nothing bad happened, >> I just got a logged Constraint_Error and the command was aborted. (Since >> the problems all came from people trying to break in, I wasn't even >> particularly upset that they weren't served...) > >So in reality it wasn't a buffer overflow as Ada caught it, while if it >had been in C you would have had a buffer overflow and possibly people >breaking in. Did I understand it correctly? Right. I think of "Constraint_Error" being raised as a detected buffer overflow, because it was trying to write outside of a buffer. Of course, its not actually doing any damage. The point, of course, is that I didn't write any code to detect this failure. Indeed, if I had realized where I'd forgotten to protect against buffer overflow, of course I would have fixed it - adding checking code beyond that would be silly. So the "being a great programmer" would not have helped here - I had already tried to detect all of the overflow cases, but I missed a few. That's called being human. Randy. Randy. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-25 10:00 ` Preben Randhol 2003-02-26 1:10 ` Randy Brukardt @ 2003-02-26 18:49 ` Stephen Leake 2003-02-27 12:09 ` Preben Randhol 2003-03-02 1:56 ` AG 1 sibling, 2 replies; 113+ messages in thread From: Stephen Leake @ 2003-02-26 18:49 UTC (permalink / raw) Preben Randhol <randhol+news@pvv.org> writes: > Randy Brukardt wrote: > > In order to avoid dynamic allocation of commands, I put the parsed > > commands into a record type with a bunch of statically bounded strings. > > These have to be carefully handled for overflow, and there were a couple > > of obscure cases where I got it wrong. Of course, nothing bad happened, > > I just got a logged Constraint_Error and the command was aborted. (Since > > the problems all came from people trying to break in, I wasn't even > > particularly upset that they weren't served...) > > So in reality it wasn't a buffer overflow as Ada caught it, I think the English meaning of the term "buffer overflow" is clear; the program tried to write more data to the buffer than it had room for. > while if it had been in C you would have had a buffer overflow and > possibly people breaking in. The _consequences_ of the buffer overflow are different in C and Ada; in Ada the overflow is caught, and handled in a way that does not allow security breaches. In poorly programmed C, the buffer overflow is not caught, and does (possibly) allow security breaches. > Did I understand it correctly? Not quite: it really is a buffer overflow :). I suppose the term "buffer overflow" has been overloaded to mean "buffer overflow that allows security breaches". But in this context, I think the more narrow meaning is appropriate. -- -- Stephe ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-26 18:49 ` Stephen Leake @ 2003-02-27 12:09 ` Preben Randhol 2003-03-01 18:16 ` Richard Riehle 2003-03-02 1:56 ` AG 1 sibling, 1 reply; 113+ messages in thread From: Preben Randhol @ 2003-02-27 12:09 UTC (permalink / raw) Stephen Leake wrote: >> So in reality it wasn't a buffer overflow as Ada caught it, > > I think the English meaning of the term "buffer overflow" is clear; > the program tried to write more data to the buffer than it had room > for. [..] > The _consequences_ of the buffer overflow are different in C and Ada; > in Ada the overflow is caught, and handled in a way that does not > allow security breaches. > > In poorly programmed C, the buffer overflow is not caught, and does > (possibly) allow security breaches. [..] > I suppose the term "buffer overflow" has been overloaded to mean > "buffer overflow that allows security breaches". But in this context, > I think the more narrow meaning is appropriate. No, the problem arrises when English meaning /= English usage. If you go saying that your program had an buffer overflow, everybody will think you had a security hole in it and that somebody took/could take advantage of this. I think it is better to look at common usage and follow this eventhough it might not follow the English spec file ;-) What about : It was a terribly good cake... (we have the same in our language by the way) -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-27 12:09 ` Preben Randhol @ 2003-03-01 18:16 ` Richard Riehle 0 siblings, 0 replies; 113+ messages in thread From: Richard Riehle @ 2003-03-01 18:16 UTC (permalink / raw) Preben Randhol wrote: > No, the problem arrises when English meaning /= English usage. If > you go saying that your program had an buffer overflow, everybody will > think you had a security hole in it and that somebody took/could take > advantage of this. I think it is better to look at common usage and > follow this eventhough it might not follow the English spec file ;-) > > What about : It was a terribly good cake... > (we have the same in our language by the way) Context, in most languages, can make a lot of difference. The chicken is ready to eat. The steak is ready to eat. The children are ready to eat. In the second sentence, there is little ambiguity. We would hope there is no ambiguity in the third sentence. Richard Riehle ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-26 18:49 ` Stephen Leake 2003-02-27 12:09 ` Preben Randhol @ 2003-03-02 1:56 ` AG 1 sibling, 0 replies; 113+ messages in thread From: AG @ 2003-03-02 1:56 UTC (permalink / raw) "Stephen Leake" <Stephen.A.Leake@nasa.gov> wrote in message news:uadgi6foa.fsf@nasa.gov... > I think the English meaning of the term "buffer overflow" is clear; > the program tried to write more data to the buffer than it had room > for. So much for the precision of the English language :) To me, "buffer overflow" means that whatever tried to write into it went over the buffer boundaries. Never mind the amount of data etc etc - the whole point of the definition is that the data went [or tried to go] beyond the allowed range. For example, if you have a buffer of 1024b and try to write three zero bytes into it starting at 1023 - will it be a buffer overflow? But the buffer itself sure had room for those 3 bytes ... ^ permalink raw reply [flat|nested] 113+ messages in thread
[parent not found: <iqeli-c2d.ln1@beastie.ix.netcom.com>]
* Re: status of PL/I as a viable language [not found] ` <iqeli-c2d.ln1@beastie.ix.netcom.com> @ 2003-02-23 5:13 ` Hyman Rosen 2003-02-28 10:32 ` Lutz Donnerhacke 0 siblings, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-23 5:13 UTC (permalink / raw) Dennis Lee Bieber wrote: > From http://www.ima.umn.edu/~arnold/disasters/patriot.html Interesting. So there was no overflow involved at all, and no language error, just a bad algorithm. So would Ada have helped any here? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-23 5:13 ` Hyman Rosen @ 2003-02-28 10:32 ` Lutz Donnerhacke 2003-02-28 18:52 ` Vinzent Hoefler 0 siblings, 1 reply; 113+ messages in thread From: Lutz Donnerhacke @ 2003-02-28 10:32 UTC (permalink / raw) * Hyman Rosen wrote: > Dennis Lee Bieber wrote: >> From http://www.ima.umn.edu/~arnold/disasters/patriot.html > > Interesting. So there was no overflow involved at all, > and no language error, just a bad algorithm. So would > Ada have helped any here? Might possible. type Time is delta 0.1; for Time'Small use 0.0; ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-28 10:32 ` Lutz Donnerhacke @ 2003-02-28 18:52 ` Vinzent Hoefler 0 siblings, 0 replies; 113+ messages in thread From: Vinzent Hoefler @ 2003-02-28 18:52 UTC (permalink / raw) Lutz Donnerhacke <lutz@iks-jena.de> wrote: > type Time is delta 0.1; > for Time'Small use 0.0; You meant "for Time'Small use 0.1", didn't you? I doubt that a value of 0.0 would be legal, see LRM 3.5.9(8) and (9). Vinzent. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:54 ` Hyman Rosen ` (5 preceding siblings ...) [not found] ` <iqeli-c2d.ln1@beastie.ix.netcom.com> @ 2003-02-23 19:19 ` Berend de Boer 2003-02-24 6:19 ` Hyman Rosen 6 siblings, 1 reply; 113+ messages in thread From: Berend de Boer @ 2003-02-23 19:19 UTC (permalink / raw) >>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes: Hyman> I've mentioned this many times before. Language checks such Hyman> as bounds checking, pointer checking, and overflow checking Hyman> are fine for testing. But when the application is released, Hyman> it is better to disable such checks in cases where Hyman> continued operation is important, because it's more likely Hyman> that a program which "gets away" with making such an error Hyman> can keep working, whereas detecting the error will just Hyman> blow the program away. I'm pretty sure that with those checks included we would have zero buffer overflow errors and your credit card info would be a lot safer. -- Regards, Berend. (-: ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-23 19:19 ` Berend de Boer @ 2003-02-24 6:19 ` Hyman Rosen 0 siblings, 0 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-24 6:19 UTC (permalink / raw) Berend de Boer wrote: > I'm pretty sure that with those checks included we would have zero > buffer overflow errors and your credit card info would be a lot safer. For the upteenth time, I qualified my statement with "when continued operation is important". It's not important for a web server to stay up when it's being attacked if it discovers that it is behaving erroneously. It is important that a rocket or an airplane which is in the middle of flying not have its software decide to shut down. As for my credit card safety, have you seen the news lately? About the easy attacks on ATM PIN numbers that can have bank insiders steal your money in fifteen tries or less? Complex software has complex failure modes. Patting yourself on the back for catching buffer overruns is a little premature. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:34 ` Hyman Rosen 2003-02-20 19:52 ` Vinzent Hoefler @ 2003-02-20 22:10 ` Peter Flass 2003-02-20 22:26 ` Chad R. Meiners 2003-02-21 9:13 ` Dmitry A. Kazakov 3 siblings, 0 replies; 113+ messages in thread From: Peter Flass @ 2003-02-20 22:10 UTC (permalink / raw) Hyman Rosen wrote: > [Patriot missle failure] > > It was an overflowed counter > This rings a bell with me, too. > Assuming that this is even true, would it have been better > if the Patriot battery threw an exception? The (first?) > Ariane 5 incident was pretty much the same, and that was in Ada. What do you want to do, reboot the missle with the Scud on the way? This is a case of "assume makes an ASS out of yoU and ME". ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:34 ` Hyman Rosen 2003-02-20 19:52 ` Vinzent Hoefler 2003-02-20 22:10 ` Peter Flass @ 2003-02-20 22:26 ` Chad R. Meiners 2003-02-21 9:13 ` Dmitry A. Kazakov 3 siblings, 0 replies; 113+ messages in thread From: Chad R. Meiners @ 2003-02-20 22:26 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1045769690.126389@master.nyc.kbcfp.com... > John R. Strohm wrote: > > So what's your point? > > My point is that the attitude I often sense on this newsgroup > is that using Ada will give you perfect code. (Not in so many > words, mind you, but definitely in attitude.) > Well I can't help you with your senses ;) but I do not sense that attitude in the majority of the posters for CLA. Perhaps you are confusing it with the "Let the compiler detect those simple program errors so you can concentrate on the complex errors" altitude. Naturally this leads to the feeling (or sense) that Ada helps build more reliable programs. -CRM ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 19:34 ` Hyman Rosen ` (2 preceding siblings ...) 2003-02-20 22:26 ` Chad R. Meiners @ 2003-02-21 9:13 ` Dmitry A. Kazakov 2003-02-21 14:56 ` Hyman Rosen 2003-02-21 19:16 ` John R. Strohm 3 siblings, 2 replies; 113+ messages in thread From: Dmitry A. Kazakov @ 2003-02-21 9:13 UTC (permalink / raw) On Thu, 20 Feb 2003 14:34:50 -0500, Hyman Rosen <hyrosen@mail.com> wrote: >John R. Strohm wrote: >> So what's your point? > >My point is that the attitude I often sense on this newsgroup >is that using Ada will give you perfect code. (Not in so many >words, mind you, but definitely in attitude.) Should it mean that an unability to create a perfect code (a thing I never saw) in one language excuses any design fault of another? --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 9:13 ` Dmitry A. Kazakov @ 2003-02-21 14:56 ` Hyman Rosen 2003-02-21 16:04 ` Preben Randhol ` (2 more replies) 2003-02-21 19:16 ` John R. Strohm 1 sibling, 3 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 14:56 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Should it mean that an unability to create a perfect code (a thing I > never saw) in one language excuses any design fault of another? Nope. I'm just objecting to "If it broke, and it's C++, it's the language's fault. If it broke, and it's Ada, it's the programmer's fault." ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:56 ` Hyman Rosen @ 2003-02-21 16:04 ` Preben Randhol 2003-02-21 19:41 ` Mike Silva 2003-02-21 20:41 ` Richard Riehle 2 siblings, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-21 16:04 UTC (permalink / raw) Hyman Rosen wrote: > Nope. I'm just objecting to "If it broke, and it's C++, it's the > language's fault. If it broke, and it's Ada, it's the programmer's > fault." No, error are always the programmers fault. However some languages like Ada makes it much harder to make common simple mistakes (not logical mistakes mind you) than other languages whoes design more or less encourage these mistakes. This leaves the programmer more time to work on reviewing the code to find the complex mistakes. One of the nice things with Ada is that you hardly need to use a debugger on smaller projects (on big projects I don't know as I don't have experience with this). But for C/C++ you sure have to use a debugger at some stage even in small projects. Looking for the needle in the haystack takes a long time compared to having the compiler tell you both the location of the haystack and where the needle is/was last seen. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:56 ` Hyman Rosen 2003-02-21 16:04 ` Preben Randhol @ 2003-02-21 19:41 ` Mike Silva 2003-02-21 20:41 ` Richard Riehle 2 siblings, 0 replies; 113+ messages in thread From: Mike Silva @ 2003-02-21 19:41 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<1045839419.823502@master.nyc.kbcfp.com>... > Dmitry A. Kazakov wrote: > > Should it mean that an unability to create a perfect code (a thing I > > never saw) in one language excuses any design fault of another? > > Nope. I'm just objecting to "If it broke, and it's C++, it's the > language's fault. If it broke, and it's Ada, it's the programmer's > fault." No, no, no! If it broke, and it's C++, it's the language's fault AND the programmer's fault. If it broke and it's Ada, it's management's fault. ;-) Hmmm, add management in the C++ case too... ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 14:56 ` Hyman Rosen 2003-02-21 16:04 ` Preben Randhol 2003-02-21 19:41 ` Mike Silva @ 2003-02-21 20:41 ` Richard Riehle 2003-02-21 21:46 ` Donald L. Dobbs 2 siblings, 1 reply; 113+ messages in thread From: Richard Riehle @ 2003-02-21 20:41 UTC (permalink / raw) Hyman Rosen wrote: > Dmitry A. Kazakov wrote: > > Should it mean that an unability to create a perfect code (a thing I > > never saw) in one language excuses any design fault of another? > > Nope. I'm just objecting to "If it broke, and it's C++, it's the > language's fault. If it broke, and it's Ada, it's the programmer's > fault." Good point. We need to understand that there are limits to what can be accomplished by depending only on our tools. Ada has a lot to recommend it for high-integrity software. Other languages have a lot to recommend them. This started as a PL/I thread, and I have learned, more recently, of improvements in PL/I since I last used it. Even so, PL/I, for all its improvements, requires skilled programmers. Ada requires skilled programmers. C++ requires skilled programmers. My personal preference, based on my experience and current knowledge of competing languages continues to be Ada, for the kind of software (such as F-22) we have been discussing. However, I realize that a highly skilled C++ programmer, one who understands the built-in pitfalls of the language, and one who understands how to use smart-pointers, smart arrays, and lots of other useful C++ classes, can create reliable software. The same is probably true of a PL/I programmer, but I am not aware of PL/I being used for many safety-critical applications. Someone can help me on that, I suppose. The key to successful safety-critical software remains, good engineering. Most programmers have no engineering education, and all too often, they have insufficient mathematics. On systems such as the F-22, it is critical that the developers are engineering aware, and that they have strong mathematics. Yesterday, I particiapted in a discussion of requirements specifications where some of the participants thought it was enough to simply specify the mathematics needed for the application. The mathematics happened to involve relatively simple calculus. The eventual design of the algorithm was expected to be the job of the programmer. Of course, there would checking, inspection, and testing at some stage, but my point was that the algorithm should be specified in more detail and not left to the programmer. As long as we ignore the importance of engineering when developing safety-critical software, we are going to continue to make a mess of it, and no programming language will save us. Ada is like using a torque wrench. C++ is like using any convenient long-handled wrench. If the mechanic is careful and has a lot of experience, using that long-handled wrench, it will work just fine. In most cases, though, we might find the toque wrench a little more reliable. However, if we have no clue about the appropriate level of torque, cannot before-hand do the required computations, and have no idea what torque is, we are going to twist off the head of the bolt just as easily as the guy with the simple long-handled wrench. Richard Riehle ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 20:41 ` Richard Riehle @ 2003-02-21 21:46 ` Donald L. Dobbs 2003-02-23 2:23 ` Shmuel (Seymour J.) Metz 2003-02-23 5:02 ` Hyman Rosen 0 siblings, 2 replies; 113+ messages in thread From: Donald L. Dobbs @ 2003-02-21 21:46 UTC (permalink / raw) Richard Riehle wrote: > Hyman Rosen wrote: > > >>Dmitry A. Kazakov wrote: >> >>>Should it mean that an unability to create a perfect code (a thing I >>>never saw) in one language excuses any design fault of another? >> >>Nope. I'm just objecting to "If it broke, and it's C++, it's the >>language's fault. If it broke, and it's Ada, it's the programmer's >>fault." > > > Good point. We need to understand that there are limits to what > can be accomplished by depending only on our tools. Ada has > a lot to recommend it for high-integrity software. Other languages > have a lot to recommend them. This started as a PL/I thread, and > I have learned, more recently, of improvements in PL/I since I > last used it. Even so, PL/I, for all its improvements, requires > skilled programmers. Ada requires skilled programmers. C++ > requires skilled programmers. > > My personal preference, based on my experience and current > knowledge of competing languages continues to be Ada, for > the kind of software (such as F-22) we have been discussing. > However, I realize that a highly skilled C++ programmer, one > who understands the built-in pitfalls of the language, and one > who understands how to use smart-pointers, smart arrays, and > lots of other useful C++ classes, can create reliable software. > The same is probably true of a PL/I programmer, but I am not > aware of PL/I being used for many safety-critical applications. > Someone can help me on that, I suppose. > > The key to successful safety-critical software remains, good > engineering. Most programmers have no engineering education, > and all too often, they have insufficient mathematics. On systems > such as the F-22, it is critical that the developers are engineering > aware, and that they have strong mathematics. > > Yesterday, I particiapted in a discussion of requirements specifications > where some of the participants thought it was enough to simply specify > the mathematics needed for the application. The mathematics happened > to involve relatively simple calculus. The eventual design of the > algorithm was expected to be the job of the programmer. Of course, > there would checking, inspection, and testing at some stage, but my > point was that the algorithm should be specified in more detail and > not left to the programmer. > > As long as we ignore the importance of engineering when developing > safety-critical software, we are going to continue to make a mess of it, > and no programming language will save us. > > Ada is like using a torque wrench. C++ is like using any convenient > long-handled wrench. If the mechanic is careful and has a lot of > experience, using that long-handled wrench, it will work just fine. In > most cases, though, we might find the toque wrench a little more > reliable. However, if we have no clue about the appropriate level > of torque, cannot before-hand do the required computations, and > have no idea what torque is, we are going to twist off the head of > the bolt just as easily as the guy with the simple long-handled wrench. > > Richard Riehle > Richard, you have touched on a subject (actually pet peeve of mine for many years in this industry) that I will elaborate on, now. When I first got into the computing business (circa 1962 -- oh my, that probably makes me older than David Frank) we had systems analysts and programmers. The latter were actually "coders". The systems analysts were subject matter experts for the application being contemplated. If it was an accounting or payroll package the S.A. was either a CPA or someone who had a strong background in accounting/bookkeeping, etc. If it was a guidance program for a missile the S.A. was probably a Ph.D. in math or celestial mechanics. The programmer (coder) only had to know his Cobol, Fortran, PL/I or assembly language. He didn't have to know the subject matter of the application to any great degree because the S.A. wrote an air-tight spec that the coder was to rigorously implement. His was not to reason why. We developed pretty good software in those days. Somewhere along the way, it all fell apart when we (as an economy measure in smaller shops, I suppose) invented the Programmer-Analyst. This, IMHO, is the worst single act that has occurred in this industry because we now expect the PA to be both subject matter expect and programmer/coder expert at the same time. The trade journals and web sites are replete with help wanted ads always demanding an individual who is a brain surgeon with ten years of Java, etc. (I exaggerate the point but not by much in many cases.) I suspect that big aerospace projects require so many bodies that there is still some division of labor, but in the commercial world this just isn't sufficiently the case. Dual experts are a rare commodity and even when you find them they have a self-contained conflict of interest because the quality of the Analyst functions will be compromised by the Coder subconscious telling himself that the requirement is too hard to implement or should be implemented in a different way which diminishes the original requirements. I suspect these opinions will instigate a whole new discussion, which I welcome because I think we've all been victim of this phenomenon, directly or indirectly. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:46 ` Donald L. Dobbs @ 2003-02-23 2:23 ` Shmuel (Seymour J.) Metz 2003-02-23 5:02 ` Hyman Rosen 1 sibling, 0 replies; 113+ messages in thread From: Shmuel (Seymour J.) Metz @ 2003-02-23 2:23 UTC (permalink / raw) In <3E569E8C.4050709@cox.net>, on 02/21/2003 at 09:46 PM, "Donald L. Dobbs" <donaldldobbs@cox.net> said: >When I first got into the computing business (circa 1962 -- oh my, >that probably makes me older than David Frank) we had systems >analysts and programmers. The latter were actually "coders". The >systems analysts were subject matter experts for the application >being contemplated. If it was an accounting or payroll package the >S.A. was either a CPA or someone who had a strong background in >accounting/bookkeeping, etc. If it was a guidance program for a >missile the S.A. was probably a Ph.D. in math or celestial >mechanics. The programmer (coder) only had to know his Cobol, >Fortran, PL/I or assembly language. He didn't have to know the >subject matter of the application to any great degree because the >S.A. wrote an air-tight spec that the coder was to rigorously >implement. His was not to reason why. We developed pretty good >software in those days. Every time someone says "I don't believe in theories.", another theory dies. What you describe was the conventional wisdom, but in practice the SA would make mistakes that the coder was not permitted to correct. It turned out to be more reliable to forget the coder-as-automaton and go back to the idea of programmers who understood what they were doing. The good software in the 1960s was *not* the stuff designed on the hermetic wall methodology. >Somewhere along the way, it all fell apart when we (as an economy >measure in smaller shops, I suppose) invented the >Programmer-Analyst. This, IMHO, is the worst single act that has >occurred in this industry While I see it as a return to sanity. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:46 ` Donald L. Dobbs 2003-02-23 2:23 ` Shmuel (Seymour J.) Metz @ 2003-02-23 5:02 ` Hyman Rosen 2003-02-23 18:34 ` Donald L. Dobbs 1 sibling, 1 reply; 113+ messages in thread From: Hyman Rosen @ 2003-02-23 5:02 UTC (permalink / raw) Donald L. Dobbs wrote: > the S.A. wrote an air-tight spec that the coder was to rigorously implement. I've rarely seen domain experts who are capable of producing air-tight specs. They have several problems. They speak in the language of their domain, which is not the language of the programmer. They know their domain so well that they fail to explain the things which are obvious to them. And because they do not think like programmers, their specs rarely cover the corner-cases, so that they leak badly rather than being air-tight. In fact, they often have no answer for what to do in these cases, because they have never seen them! ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-23 5:02 ` Hyman Rosen @ 2003-02-23 18:34 ` Donald L. Dobbs 2003-02-24 6:22 ` Hyman Rosen 0 siblings, 1 reply; 113+ messages in thread From: Donald L. Dobbs @ 2003-02-23 18:34 UTC (permalink / raw) Hyman Rosen wrote: > Donald L. Dobbs wrote: > >> the S.A. wrote an air-tight spec that the coder was to rigorously >> implement. > > > I've rarely seen domain experts who are capable of producing air-tight > specs. > They have several problems. They speak in the language of their domain, > which > is not the language of the programmer. They know their domain so well that > they fail to explain the things which are obvious to them. And because they > do not think like programmers, their specs rarely cover the > corner-cases, so > that they leak badly rather than being air-tight. In fact, they often > have no > answer for what to do in these cases, because they have never seen them! > You have obviously never worked on a really huge software development project. Also, you are assuming that no further discourse takes place between analyst and programmer and that there are no reviews and checkpoints along the way. If you have a subject matter expert and an excellent programmer both assigned to a project you get the best of both worlds. When you try to find some one individual who purports to be both you end up with mediocre subject matter expertise compromised by the conflict of interest because the programmer hat is telling the subject matter hat to go easy on certain legitimate requirements. There is tons of crap in the marketplace today that tries to pass itself off as software. It is usually incomplete from a domain standpoint and is poorly coded to boot. It takes a beta release and several version upgrades before the product really becomes useful. The manufacturer is letting the customer (the subject matter expert in this case) do his homework for him -- both in design and debugging. We just didn't have those situations with the products I was associated with. I've observed both approaches, been involved in both approaches and experienced both approaches. I merely report my observations and remain unmoved by your response. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-23 18:34 ` Donald L. Dobbs @ 2003-02-24 6:22 ` Hyman Rosen 0 siblings, 0 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-24 6:22 UTC (permalink / raw) Donald L. Dobbs wrote: > I've observed both approaches, been involved in both approaches and > experienced both approaches. I merely report my observations and remain > unmoved by your response. Come to think of it, this is probably what caused the Y2K problem. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 9:13 ` Dmitry A. Kazakov 2003-02-21 14:56 ` Hyman Rosen @ 2003-02-21 19:16 ` John R. Strohm 2003-02-21 19:49 ` Hyman Rosen 2003-02-21 21:44 ` Pointless Harlows 1 sibling, 2 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-21 19:16 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:f2rb5v8020kkvq6tsf0uqg91pfbk9errs7@4ax.com... > On Thu, 20 Feb 2003 14:34:50 -0500, Hyman Rosen <hyrosen@mail.com> > wrote: > > >John R. Strohm wrote: > >> So what's your point? > > > >My point is that the attitude I often sense on this newsgroup > >is that using Ada will give you perfect code. (Not in so many > >words, mind you, but definitely in attitude.) > > Should it mean that an unability to create a perfect code (a thing I > never saw) in one language excuses any design fault of another? Actually, it IS possible to create perfect code. See: http://www.cs.utexas.edu/users/boyer/ftp/ics-reports/cmp34.pdf ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 19:16 ` John R. Strohm @ 2003-02-21 19:49 ` Hyman Rosen 2003-02-21 20:32 ` Frank J. Lhota 2003-02-21 20:35 ` John R. Strohm 2003-02-21 21:44 ` Pointless Harlows 1 sibling, 2 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 19:49 UTC (permalink / raw) John R. Strohm wrote: > Actually, it IS possible to create perfect code. See: > http://www.cs.utexas.edu/users/boyer/ftp/ics-reports/cmp34.pdf It took them almost two years to write a simple little limited regular expression matcher. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 19:49 ` Hyman Rosen @ 2003-02-21 20:32 ` Frank J. Lhota 2003-02-21 20:40 ` John R. Strohm 2003-02-21 20:35 ` John R. Strohm 1 sibling, 1 reply; 113+ messages in thread From: Frank J. Lhota @ 2003-02-21 20:32 UTC (permalink / raw) > It took them almost two years to write a simple little > limited regular expression matcher. When it comes to software (or hardware, or buildings, or novels, or just about everything), customers want three things: they want it fast, they want it cheap, and they want it good. Generally, you can provide them with any combination of two of these three things. AFAIK, this is an example of someone producing software that is cheap and extremely good, and the expense of not being very fast. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 20:32 ` Frank J. Lhota @ 2003-02-21 20:40 ` John R. Strohm 0 siblings, 0 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-21 20:40 UTC (permalink / raw) "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:T1w5a.53$8f7.22@nwrdny02.gnilink.net... > > It took them almost two years to write a simple little > > limited regular expression matcher. > > When it comes to software (or hardware, or buildings, or novels, or just > about everything), customers want three things: they want it fast, they want > it cheap, and they want it good. Generally, you can provide them with any > combination of two of these three things. AFAIK, this is an example of > someone producing software that is cheap and extremely good, and the expense > of not being very fast. It wasn't cheap. It wasn't extremely good; it was PERFECT. It did PRECISELY what it was designed to do. It did PRECISELY what the customer WANTED it to do. And it didn't just CLAIM to do that, and CLAIM to have no lurking faults; it was rigorously KNOWN to have no lurking faults. This was part of a long project aimed at developing verification technology to the point that it would be possible to build perfect software. One can easily envision domains where exhaustive testing is just not possible, where it is necessary to KNOW by other techniques that the software is absolutely, positively, correct. In those domains, "debugging" until it LOOKS like it works just isn't good enough. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 19:49 ` Hyman Rosen 2003-02-21 20:32 ` Frank J. Lhota @ 2003-02-21 20:35 ` John R. Strohm 2003-02-21 21:40 ` Hyman Rosen 1 sibling, 1 reply; 113+ messages in thread From: John R. Strohm @ 2003-02-21 20:35 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1045856952.418085@master.nyc.kbcfp.com... > John R. Strohm wrote: > > Actually, it IS possible to create perfect code. See: > > http://www.cs.utexas.edu/users/boyer/ftp/ics-reports/cmp34.pdf > > It took them almost two years to write a simple little > limited regular expression matcher. And that "simple little limited regular expression matcher" passed the formal customer acceptance test on the first try, with no deviations or waivers or anything. They never saw the acceptance test suite until the formal test, in front of the customer. The acceptance test was developed by a different company, in California. That was the FIRST time *ANY* computer program had EVER done that, in all the history of the U.S. Department of Defense. The critical part of the project was the verification. They KNEW that the code was correct, because they'd proven it, with mathematical rigor, subject to the one assumed lemma about the ordering of certain characters in the ASCII character code. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 20:35 ` John R. Strohm @ 2003-02-21 21:40 ` Hyman Rosen 2003-02-21 22:25 ` John R. Strohm ` (2 more replies) 0 siblings, 3 replies; 113+ messages in thread From: Hyman Rosen @ 2003-02-21 21:40 UTC (permalink / raw) John R. Strohm wrote: > And that "simple little limited regular expression matcher" passed the > formal customer acceptance test on the first try, with no deviations or > waivers or anything. But it took them *two years* to get it specified, designed, and built. Maybe it was a polished piece of perfection, but that's a very long time to build a message filter. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:40 ` Hyman Rosen @ 2003-02-21 22:25 ` John R. Strohm 2003-02-22 10:56 ` Preben Randhol 2003-02-22 19:55 ` Everett M. Greene 2 siblings, 0 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-21 22:25 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1045863617.243086@master.nyc.kbcfp.com... > John R. Strohm wrote: > > And that "simple little limited regular expression matcher" passed the > > formal customer acceptance test on the first try, with no deviations or > > waivers or anything. > > But it took them *two years* to get it specified, > designed, and built. Maybe it was a polished piece > of perfection, but that's a very long time to build > a message filter. Depends on what kind of defect density you can tolerate, and on whether you can afford to find the defects in actual operation. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:40 ` Hyman Rosen 2003-02-21 22:25 ` John R. Strohm @ 2003-02-22 10:56 ` Preben Randhol 2003-02-22 19:55 ` Everett M. Greene 2003-02-22 19:55 ` Everett M. Greene 2 siblings, 1 reply; 113+ messages in thread From: Preben Randhol @ 2003-02-22 10:56 UTC (permalink / raw) Hyman Rosen wrote: > But it took them *two years* to get it specified, designed, and built. > Maybe it was a polished piece of perfection, but that's a very long > time to build a message filter. But two years is nothing! -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 10:56 ` Preben Randhol @ 2003-02-22 19:55 ` Everett M. Greene 2003-02-23 11:15 ` Preben Randhol 0 siblings, 1 reply; 113+ messages in thread From: Everett M. Greene @ 2003-02-22 19:55 UTC (permalink / raw) Preben Randhol <randhol+news@pvv.org> writes: > Hyman Rosen wrote: > > But it took them *two years* to get it specified, designed, and built. > > Maybe it was a polished piece of perfection, but that's a very long > > time to build a message filter. > > But two years is nothing! On a six-month schedule? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 19:55 ` Everett M. Greene @ 2003-02-23 11:15 ` Preben Randhol 0 siblings, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-23 11:15 UTC (permalink / raw) Everett M. Greene wrote: > Preben Randhol <randhol+news@pvv.org> writes: >> Hyman Rosen wrote: >> > But it took them *two years* to get it specified, designed, and built. >> > Maybe it was a polished piece of perfection, but that's a very long >> > time to build a message filter. >> >> But two years is nothing! > > On a six-month schedule? Yes -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:40 ` Hyman Rosen 2003-02-21 22:25 ` John R. Strohm 2003-02-22 10:56 ` Preben Randhol @ 2003-02-22 19:55 ` Everett M. Greene 2003-02-22 20:03 ` John R. Strohm 2 siblings, 1 reply; 113+ messages in thread From: Everett M. Greene @ 2003-02-22 19:55 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > John R. Strohm wrote: > > And that "simple little limited regular expression matcher" passed the > > formal customer acceptance test on the first try, with no deviations or > > waivers or anything. > > But it took them *two years* to get it specified, designed, and built. > Maybe it was a polished piece of perfection, but that's a very long > time to build a message filter. One has to consider the economics of the situation. Is perfection a requirement or just a target? There is a point of diminishing returns beyond which it isn't worth the time and expense to ensure perfection. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 19:55 ` Everett M. Greene @ 2003-02-22 20:03 ` John R. Strohm 2003-02-22 22:38 ` Larry Kilgallen 0 siblings, 1 reply; 113+ messages in thread From: John R. Strohm @ 2003-02-22 20:03 UTC (permalink / raw) "Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message news:20030222.7982838.ABFA@mojaveg.iwvisp.com... > Hyman Rosen <hyrosen@mail.com> writes: > > John R. Strohm wrote: > > > And that "simple little limited regular expression matcher" passed the > > > formal customer acceptance test on the first try, with no deviations or > > > waivers or anything. > > > > But it took them *two years* to get it specified, designed, and built. > > Maybe it was a polished piece of perfection, but that's a very long > > time to build a message filter. > > One has to consider the economics of the situation. Is perfection > a requirement or just a target? There is a point of diminishing > returns beyond which it isn't worth the time and expense to ensure > perfection. In this case, perfection was a requirement. The message flow modulator is a filter. Grossly oversimplifying, the data line carried messages with varying security markings. Anything carrying certain marks had to be stopped. You really don't want a previously-undiscovered bug in your security box to hand a Top Secret / compartmented message to someone who is not allowed to receive it. You REALLY don't want to find out that it has been doing that for over a year. In this application, you have to KNOW that there are no bugs in the software. You have to PROVE it. Testing just isn't good enough to get you there. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 20:03 ` John R. Strohm @ 2003-02-22 22:38 ` Larry Kilgallen 0 siblings, 0 replies; 113+ messages in thread From: Larry Kilgallen @ 2003-02-22 22:38 UTC (permalink / raw) In article <828DE23B3B00B2F4.378802739B5A1D47.F69B281EC119A34F@lp.airnews.net>, "John R. Strohm" <strohm@airmail.net> writes: > "Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message > news:20030222.7982838.ABFA@mojaveg.iwvisp.com... >> One has to consider the economics of the situation. Is perfection >> a requirement or just a target? There is a point of diminishing >> returns beyond which it isn't worth the time and expense to ensure >> perfection. > You really don't want a previously-undiscovered bug in your security box to > hand a Top Secret / compartmented message to someone who is not allowed to > receive it. You REALLY don't want to find out that it has been doing that > for over a year. In this application, you have to KNOW that there are no > bugs in the software. You have to PROVE it. Testing just isn't good enough > to get you there. And based on that description, the decision regarding the need for perfection was made by the people in charge of the funding. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 19:16 ` John R. Strohm 2003-02-21 19:49 ` Hyman Rosen @ 2003-02-21 21:44 ` Pointless Harlows 2003-02-22 4:51 ` John W. Kennedy 1 sibling, 1 reply; 113+ messages in thread From: Pointless Harlows @ 2003-02-21 21:44 UTC (permalink / raw) "John R. Strohm" <strohm@airmail.net> wrote in message > Actually, it IS possible to create perfect code. You may recall the perfect IBM mainframe utility routine IEFBR14 ;-) However, I did hear it said once that even the first version of IEFBR14 had a fault in that it didnt return a zero return code. Can anyone actually confirm that? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 21:44 ` Pointless Harlows @ 2003-02-22 4:51 ` John W. Kennedy 2003-02-23 0:13 ` James J. Weinkam 0 siblings, 1 reply; 113+ messages in thread From: John W. Kennedy @ 2003-02-22 4:51 UTC (permalink / raw) Pointless Harlows wrote: > You may recall the perfect IBM mainframe utility routine IEFBR14 ;-) > However, I did hear it said once that even the first version of IEFBR14 had > a fault in that it didnt return a zero return code. > Can anyone actually confirm that? The story is quite true; I remember it well. It had a second fault; it wasn't tagged re-entrant. I've heard that it had a third, but it must have been documentation-only. Of course, every "Hello World" program is perfect. And I once tested a Julian-date converter (the _real_ Julian date -- serially numbered days from January 1, 4713 BC) to exhaustion, so it was perfect, too. -- John W. Kennedy "The poor have sometimes objected to being governed badly; the rich have always objected to being governed at all." -- G. K. Chesterton, "The Man Who Was Thursday" ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 4:51 ` John W. Kennedy @ 2003-02-23 0:13 ` James J. Weinkam 2003-02-23 2:28 ` John W. Kennedy 0 siblings, 1 reply; 113+ messages in thread From: James J. Weinkam @ 2003-02-23 0:13 UTC (permalink / raw) John W. Kennedy wrote: > > And I once tested a Julian-date converter (the _real_ Julian date -- > serially numbered days from January 1, 4713 BC) to exhaustion, so it was > perfect, too. > Did you test it to exhaustion if the forward as well as the backward direction? :) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-23 0:13 ` James J. Weinkam @ 2003-02-23 2:28 ` John W. Kennedy 0 siblings, 0 replies; 113+ messages in thread From: John W. Kennedy @ 2003-02-23 2:28 UTC (permalink / raw) James J. Weinkam wrote: > John W. Kennedy wrote: >> And I once tested a Julian-date converter (the _real_ Julian date -- >> serially numbered days from January 1, 4713 BC) to exhaustion, so it >> was perfect, too. > Did you test it to exhaustion if the forward as well as the backward > direction? :) Yup. The original algorithms as I received them had used floating point, with unstated assumptions about precision and rounding, so I adjusted them to do all calculations with positive integers, so that I could be sure that, no matter what language or system I ported to in the future, it would work. Having made so fundamental a change, I wanted to be sure that I got it right. Doing the two-way test over the entire range was just an overnight on a 4.77MHz 8088. -- John W. Kennedy "The poor have sometimes objected to being governed badly; the rich have always objected to being governed at all." -- G. K. Chesterton, "The Man Who Was Thursday" ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 18:44 ` John R. Strohm 2003-02-20 19:09 ` Larry Kilgallen 2003-02-20 19:34 ` Hyman Rosen @ 2003-02-20 21:45 ` Larry Kilgallen 2003-02-20 22:06 ` Peter Flass ` (4 subsequent siblings) 7 siblings, 0 replies; 113+ messages in thread From: Larry Kilgallen @ 2003-02-20 21:45 UTC (permalink / raw) In article <1045772065.590669@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes: > Which is to say, complex systems can have complex failure modes, > and the fact that some programming languages will catch simple > errors isn't going to help at all with the complex ones. The average denizen of comp.lang.ada does not claim that compiler capabilities will solve all problems. Some of us claim they _help_ with complex problems by freeing the humans from obsessing over simple bugs, allowing more time for consideration of complex issues. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 18:44 ` John R. Strohm ` (2 preceding siblings ...) 2003-02-20 21:45 ` Larry Kilgallen @ 2003-02-20 22:06 ` Peter Flass 2003-02-20 23:30 ` John R. Strohm 2003-02-20 22:34 ` Larry Kilgallen ` (3 subsequent siblings) 7 siblings, 1 reply; 113+ messages in thread From: Peter Flass @ 2003-02-20 22:06 UTC (permalink / raw) "John R. Strohm" wrote: > The last bug I found and fixed at my last employer was a null pointer > access. That company has an internal coding policy that pointers will > ALWAYS be tested for null before being dereferenced. I would submit that this should be done by hardware, not software (i.e. location 0, assuming null is 0) should be fetch-protected from everywhere but a few O/S routines. Anything else is a colossal waste of computing resources. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 22:06 ` Peter Flass @ 2003-02-20 23:30 ` John R. Strohm 2003-02-21 13:46 ` Peter Flass 2003-02-21 20:26 ` Shmuel (Seymour J.) Metz 0 siblings, 2 replies; 113+ messages in thread From: John R. Strohm @ 2003-02-20 23:30 UTC (permalink / raw) "Peter Flass" <peter_flass@yahoo.com> wrote in message news:3E554AF4.C8F0EF2E@yahoo.com... > "John R. Strohm" wrote: > > The last bug I found and fixed at my last employer was a null pointer > > access. That company has an internal coding policy that pointers will > > ALWAYS be tested for null before being dereferenced. > > I would submit that this should be done by hardware, not software (i.e. > location 0, assuming null is 0) should be fetch-protected from > everywhere but a few O/S routines. Anything else is a colossal waste of > computing resources. On just about every machine I've ever dealt with, dereferencing a null pointer throws a hardware trap. Dereferencing a null pointer is ALWAYS an error. It may be a case of "This pointer should NEVER be null" or it may be a case of "OK, there is no existing entry for this object, so we have to create a new one". Catching a hardware trap and recovering from it is almost always MUCH more expensive than checking a pointer for null. It gets seriously ugly if you are trying to control the granularity of the trap catching code, so you know that an exception handled here could only be a pointer fault. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 23:30 ` John R. Strohm @ 2003-02-21 13:46 ` Peter Flass 2003-02-21 20:33 ` Shmuel (Seymour J.) Metz 2003-02-21 20:26 ` Shmuel (Seymour J.) Metz 1 sibling, 1 reply; 113+ messages in thread From: Peter Flass @ 2003-02-21 13:46 UTC (permalink / raw) "John R. Strohm" wrote: > > "Peter Flass" <peter_flass@yahoo.com> wrote in message > news:3E554AF4.C8F0EF2E@yahoo.com... > > "John R. Strohm" wrote: > > > The last bug I found and fixed at my last employer was a null pointer > > > access. That company has an internal coding policy that pointers will > > > ALWAYS be tested for null before being dereferenced. > > > > I would submit that this should be done by hardware, not software (i.e. > > location 0, assuming null is 0) should be fetch-protected from > > everywhere but a few O/S routines. Anything else is a colossal waste of > > computing resources. > > On just about every machine I've ever dealt with, dereferencing a null > pointer throws a hardware trap. Dereferencing a null pointer is ALWAYS an > error. It may be a case of "This pointer should NEVER be null" or it may be > a case of "OK, there is no existing entry for this object, so we have to > create a new one". Well, not "always", remember some O/S code has to access virtual address 0, but almost always. > > Catching a hardware trap and recovering from it is almost always MUCH more > expensive than checking a pointer for null. It gets seriously ugly if you > are trying to control the granularity of the trap catching code, so you know > that an exception handled here could only be a pointer fault. Right, except that dreferencing a null pointer is an *error*, and should not occur in normal code. Better to let the hardware trap it for the 1 in 10**6 times it may occur than execute a lot of useless checking every time you run the program. Just so someone checks. As for granularity, I'm reading this on comp.lang.pl1 and not comp.lang.ada. PL/I provides the tools to handle this, as long as the programmer puts a litt;e thought into the design. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 13:46 ` Peter Flass @ 2003-02-21 20:33 ` Shmuel (Seymour J.) Metz 0 siblings, 0 replies; 113+ messages in thread From: Shmuel (Seymour J.) Metz @ 2003-02-21 20:33 UTC (permalink / raw) In <3E56203D.BD1F694@yahoo.com>, on 02/21/2003 at 01:46 PM, Peter Flass <peter_flass@yahoo.com> said: >Well, not "always", remember some O/S code has to access virtual >address 0, but almost always. That depends very much on the architecture. It's certainly true on the more common systems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 23:30 ` John R. Strohm 2003-02-21 13:46 ` Peter Flass @ 2003-02-21 20:26 ` Shmuel (Seymour J.) Metz 1 sibling, 0 replies; 113+ messages in thread From: Shmuel (Seymour J.) Metz @ 2003-02-21 20:26 UTC (permalink / raw) In <819A9E0CA1094B88.6E582670555DCA33.F06C4B2BCD076570@lp.airnews.net>, on 02/20/2003 at 05:30 PM, "John R. Strohm" <strohm@airmail.net> said: >On just about every machine I've ever dealt with, dereferencing a >null pointer throws a hardware trap. If the compiler takes the easy route and represents a null pointer as 0, there won't be a hardware trap on, e.g., a system running MVS[1] or VM[2]. >Catching a hardware trap and recovering from it is almost always >MUCH more expensive than checking a pointer for null. Why do you care? Explicitly testing is always much more expensive when the pointer is valid, which is much more common, so in aggregate it is more expensive than using an invalid address for null and letting the hardware catch it. Your argument only holds water if the path for handling an exception is itself time critical. [1] Of any vintage from OS/VS2 R2 through z/OS. [2] Of any vintage from VMF/370 through z/VM. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 18:44 ` John R. Strohm ` (3 preceding siblings ...) 2003-02-20 22:06 ` Peter Flass @ 2003-02-20 22:34 ` Larry Kilgallen [not found] ` <1lagi-b33.ln1@beastie.ix.netcom.com> ` (2 subsequent siblings) 7 siblings, 0 replies; 113+ messages in thread From: Larry Kilgallen @ 2003-02-20 22:34 UTC (permalink / raw) In article <3E554AF4.C8F0EF2E@yahoo.com>, Peter Flass <peter_flass@yahoo.com> writes: > "John R. Strohm" wrote: >> The last bug I found and fixed at my last employer was a null pointer >> access. That company has an internal coding policy that pointers will >> ALWAYS be tested for null before being dereferenced. > > I would submit that this should be done by hardware, not software (i.e. > location 0, assuming null is 0) should be fetch-protected from Typically it is, and an exception will be thrown. Coding standards to test first typically include the notion that some reasonable action should be taken in lieu of the fetch. > everywhere but a few O/S routines. Anything else is a colossal waste of > computing resources. Once you are handling exceptions, performance is not very important, since exceptions are, by definition, not supposed to be the normal course of events. ^ permalink raw reply [flat|nested] 113+ messages in thread
[parent not found: <1lagi-b33.ln1@beastie.ix.netcom.com>]
* Re: status of PL/I as a viable language [not found] ` <1lagi-b33.ln1@beastie.ix.netcom.com> @ 2003-02-21 16:09 ` Preben Randhol 0 siblings, 0 replies; 113+ messages in thread From: Preben Randhol @ 2003-02-21 16:09 UTC (permalink / raw) Dennis Lee Bieber wrote: > I seem to recall reading that the Patriot timer was a problem in M$ > Windows itself... a 49day uptime for W95 or something? Patriots run on Windows? Mamma mia *tremble* -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 18:44 ` John R. Strohm ` (5 preceding siblings ...) [not found] ` <1lagi-b33.ln1@beastie.ix.netcom.com> @ 2003-02-21 18:10 ` Larry Kilgallen 2003-02-24 12:00 ` Larry Kilgallen 7 siblings, 0 replies; 113+ messages in thread From: Larry Kilgallen @ 2003-02-21 18:10 UTC (permalink / raw) In article <1045845919.135559@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes: > Preben Randhol wrote: >> So your point is that it is better to use C/C++ which doesn't have these >> test in the first place? > > Oh no, not at all. It's much better for the checks to be there. > But you have to be aware of their limitations, and know when > you want to disable them. > >> How come there are so many security holes in software then? > > My point was that checks should be disabled when it is > important for programs to continue operation. For the Patriot case, I think "continue operations" is the wrong action in the presence of an error, since the whole system deploys explosives "somewhere". ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 18:44 ` John R. Strohm ` (6 preceding siblings ...) 2003-02-21 18:10 ` Larry Kilgallen @ 2003-02-24 12:00 ` Larry Kilgallen 7 siblings, 0 replies; 113+ messages in thread From: Larry Kilgallen @ 2003-02-24 12:00 UTC (permalink / raw) In article <UPi6a.4466$8f7.333@nwrdny02.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes: > As for my credit card safety, have you seen the news lately? About > the easy attacks on ATM PIN numbers that can have bank insiders > steal your money in fifteen tries or less? Complex software has > complex failure modes. Patting yourself on the back for catching > buffer overruns is a little premature. Patting oneself on the back for always avoiding automated tools for catching buffer overflows is also silly, and some C* programmers do that. (Yes, I group C, C++, C# all together, because many of their advocates do, praising the ability to write C with a C++ compiler.) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-20 17:58 ` Hyman Rosen 2003-02-20 18:44 ` John R. Strohm @ 2003-02-21 20:16 ` Shmuel (Seymour J.) Metz 2003-02-22 12:57 ` Peter Flass 1 sibling, 1 reply; 113+ messages in thread From: Shmuel (Seymour J.) Metz @ 2003-02-21 20:16 UTC (permalink / raw) In <1045763933.848350@master.nyc.kbcfp.com>, on 02/20/2003 at 12:58 PM, Hyman Rosen <hyrosen@mail.com> said: >The problem is that those errors which are caught are gross errors of >coding - buffer overruns, null pointer accesses, arithmetic overflow, >etc. But serious errors in complex software aren't caused (only) by >these sorts of errors. True. But a huge proportion of the exploits in Internet software rely on buffer underruns, which wouldn't exist in a language like Ada that has an equivalent to SUBSCRIPTRANGE. And, yes, the checking can be turned off in Ada, but I would hope that such an abomination would never get through code review. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-21 20:16 ` Shmuel (Seymour J.) Metz @ 2003-02-22 12:57 ` Peter Flass 2003-02-23 2:27 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 113+ messages in thread From: Peter Flass @ 2003-02-22 12:57 UTC (permalink / raw) "Shmuel (Seymour J.) Metz" wrote: > > True. But a huge proportion of the exploits in Internet software rely > on buffer underruns, which wouldn't exist in a language like Ada that > has an equivalent to SUBSCRIPTRANGE. And, yes, the checking can be > turned off in Ada, but I would hope that such an abomination would > never get through code review. Once again, it all depends. If I write (PL/I) code like: DO i=LBOUND(array,1) TO HBOUND(array,1); ... I'm *guaranteed* that I'll never have a subscript problem, no matter what, and range checking is redundant. If I take some random value read from a file and try to use it as a subscript, a range check might be appropriate, although I'd prefer to do the check myself to better handle the resulting error. Most of the internet problems are caused by a conbination of C, which leaves itself wide open to overflow/underflow, and poor programming, which can be found in any language. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: status of PL/I as a viable language 2003-02-22 12:57 ` Peter Flass @ 2003-02-23 2:27 ` Shmuel (Seymour J.) Metz 0 siblings, 0 replies; 113+ messages in thread From: Shmuel (Seymour J.) Metz @ 2003-02-23 2:27 UTC (permalink / raw) In <3E574AF3.73E9C38A@yahoo.com>, on 02/22/2003 at 12:57 PM, Peter Flass <peter_flass@yahoo.com> said: >Once again, it all depends. If I write (PL/I) Ah, but the exploits tend to involve C code, where there is no bounds check. >I'd prefer to do the check myself Well, if I saw (NOSUBSCRIPTRANGE) or (NOSTRINGRANGE) in a code review, I'd raise a red flag. But I wouldn't complain about a redundant validity check. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 113+ messages in thread
end of thread, other threads:[~2003-03-04 12:11 UTC | newest] Thread overview: 113+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-20 23:00 status of PL/I as a viable language David C. Hoos, Sr. -- strict thread matches above, loose matches on Subject: below -- 2003-02-26 20:55 David C. Hoos 2003-02-27 12:12 ` Preben Randhol 2003-02-22 13:26 David C. Hoos, Sr. 2003-02-21 18:17 Lionel.DRAGHI 2003-02-21 18:44 ` Hyman Rosen [not found] <mHZ0a.42983$jM5.108891@newsfeeds.bigpond.com> [not found] ` <nRg1a.190899$HG.32437469@news4.srv.hcvlny.cv.net> [not found] ` <3E51908E.9CCA3412@adaworks.com> [not found] ` <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net> [not found] ` <3E51ABCE.5491B9A2@adaworks.com> [not found] ` <b2spe6$p23$1@helle.btinternet.com> [not found] ` <3E5273DE.2050206@cox.net> [not found] ` <3E531E6F.BDFB2599@adaworks.com> [not found] ` <3E546C45.4010406@cox.net> 2003-02-20 15:49 ` Richard Riehle 2003-02-20 16:26 ` Donald L. Dobbs 2003-02-20 17:15 ` Preben Randhol 2003-02-21 6:24 ` Anders Wirzenius 2003-02-21 18:44 ` John R. Strohm 2003-02-20 17:58 ` Hyman Rosen 2003-02-20 18:44 ` John R. Strohm 2003-02-20 19:09 ` Larry Kilgallen 2003-02-20 19:27 ` John R. Strohm 2003-02-20 19:48 ` Hyman Rosen 2003-02-20 21:12 ` John R. Strohm 2003-02-20 21:39 ` Bobby D. Bryant 2003-02-21 20:36 ` Randy Brukardt 2003-02-21 8:33 ` Jean-Pierre Rosen 2003-02-20 19:34 ` Hyman Rosen 2003-02-20 19:52 ` Vinzent Hoefler 2003-02-20 20:14 ` Hyman Rosen 2003-02-20 21:20 ` Vinzent Hoefler 2003-02-21 8:14 ` Ondřej Tučný 2003-02-21 14:54 ` Hyman Rosen 2003-02-21 15:05 ` Vinzent Hoefler 2003-02-21 15:55 ` Preben Randhol 2003-02-21 16:45 ` Hyman Rosen 2003-02-21 17:40 ` Preben Randhol 2003-02-21 17:44 ` Preben Randhol 2003-02-21 18:10 ` Hyman Rosen 2003-02-21 18:38 ` Preben Randhol 2003-02-21 18:40 ` Preben Randhol 2003-02-21 18:52 ` Hyman Rosen 2003-02-21 19:24 ` Vinzent Hoefler 2003-02-21 19:57 ` Hyman Rosen 2003-02-21 20:37 ` Vinzent Hoefler 2003-02-21 20:55 ` Randy Brukardt 2003-02-21 18:42 ` Vinzent Hoefler 2003-02-21 18:48 ` John R. Strohm 2003-02-21 20:22 ` Richard Riehle 2003-02-21 20:51 ` Randy Brukardt 2003-02-21 21:29 ` Hyman Rosen 2003-02-21 21:44 ` Vinzent Hoefler 2003-02-23 5:05 ` Hyman Rosen 2003-02-24 16:29 ` Vinzent Hoefler 2003-02-22 11:06 ` Preben Randhol 2003-02-23 22:04 ` tmoran 2003-02-24 9:32 ` Preben Randhol 2003-03-02 2:37 ` AG 2003-03-01 13:46 ` Preben Randhol 2003-03-03 0:57 ` AG 2003-03-02 12:40 ` Preben Randhol 2003-03-02 16:52 ` John R. Strohm 2003-03-03 0:19 ` Georg Bauhaus 2003-03-03 3:03 ` John R. Strohm 2003-03-04 12:11 ` Faust 2003-03-03 8:01 ` Preben Randhol 2003-02-24 20:15 ` Randy Brukardt 2003-02-25 10:00 ` Preben Randhol 2003-02-26 1:10 ` Randy Brukardt 2003-02-26 18:49 ` Stephen Leake 2003-02-27 12:09 ` Preben Randhol 2003-03-01 18:16 ` Richard Riehle 2003-03-02 1:56 ` AG [not found] ` <iqeli-c2d.ln1@beastie.ix.netcom.com> 2003-02-23 5:13 ` Hyman Rosen 2003-02-28 10:32 ` Lutz Donnerhacke 2003-02-28 18:52 ` Vinzent Hoefler 2003-02-23 19:19 ` Berend de Boer 2003-02-24 6:19 ` Hyman Rosen 2003-02-20 22:10 ` Peter Flass 2003-02-20 22:26 ` Chad R. Meiners 2003-02-21 9:13 ` Dmitry A. Kazakov 2003-02-21 14:56 ` Hyman Rosen 2003-02-21 16:04 ` Preben Randhol 2003-02-21 19:41 ` Mike Silva 2003-02-21 20:41 ` Richard Riehle 2003-02-21 21:46 ` Donald L. Dobbs 2003-02-23 2:23 ` Shmuel (Seymour J.) Metz 2003-02-23 5:02 ` Hyman Rosen 2003-02-23 18:34 ` Donald L. Dobbs 2003-02-24 6:22 ` Hyman Rosen 2003-02-21 19:16 ` John R. Strohm 2003-02-21 19:49 ` Hyman Rosen 2003-02-21 20:32 ` Frank J. Lhota 2003-02-21 20:40 ` John R. Strohm 2003-02-21 20:35 ` John R. Strohm 2003-02-21 21:40 ` Hyman Rosen 2003-02-21 22:25 ` John R. Strohm 2003-02-22 10:56 ` Preben Randhol 2003-02-22 19:55 ` Everett M. Greene 2003-02-23 11:15 ` Preben Randhol 2003-02-22 19:55 ` Everett M. Greene 2003-02-22 20:03 ` John R. Strohm 2003-02-22 22:38 ` Larry Kilgallen 2003-02-21 21:44 ` Pointless Harlows 2003-02-22 4:51 ` John W. Kennedy 2003-02-23 0:13 ` James J. Weinkam 2003-02-23 2:28 ` John W. Kennedy 2003-02-20 21:45 ` Larry Kilgallen 2003-02-20 22:06 ` Peter Flass 2003-02-20 23:30 ` John R. Strohm 2003-02-21 13:46 ` Peter Flass 2003-02-21 20:33 ` Shmuel (Seymour J.) Metz 2003-02-21 20:26 ` Shmuel (Seymour J.) Metz 2003-02-20 22:34 ` Larry Kilgallen [not found] ` <1lagi-b33.ln1@beastie.ix.netcom.com> 2003-02-21 16:09 ` Preben Randhol 2003-02-21 18:10 ` Larry Kilgallen 2003-02-24 12:00 ` Larry Kilgallen 2003-02-21 20:16 ` Shmuel (Seymour J.) Metz 2003-02-22 12:57 ` Peter Flass 2003-02-23 2:27 ` Shmuel (Seymour J.) Metz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox