Faulty languages and Liability

Faulty languages and Liability

[David Botton]

I have been saying for year the day would come that software authors would
start to be found liable for their bugs... the time is approaching....

http://story.news.yahoo.com/news?tmpl=story&u=/nm/20020615/tc_nm/bizliabilit
y_software_dc_1

<<
Researchers on both sides of the Atlantic say most reported security
incidents are due to software defects that could easily be fixed.
>>

Using Ada is the first step to solving these problems! Now we need to get
some spokes people to help these lawyers go after faulty software
manufactures for using faulty languages too :-)

David Botton

Re: Faulty languages and Liability

[Lyle McKennot]

"David Botton" <David@Botton.com> wrote:

 
>Using Ada is the first step to solving these problems! 

It is a bit too late for good old Ada.

Now, if the name could be changed, the syntax altered to look like C++
( Yuck ! ) and MS persuaded to market it as Bill .NET, then it might
have a chance :-)

RE: Faulty languages and Liability

[Robert C. Leif]

From: Bob Leif
To: Lyle McKennot et al.

The Ada vendors can easily get Bill Gates' blessing. All they have to do
is to make their products work with .net and list them at the .net web
site. For Microsoft, Ada has two great virtues. 1) Ada is not Java. 2)
Ada can be used to impugn both SUN's and IBM's credibility. 

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Lyle McKennot
Sent: Saturday, June 15, 2002 8:18 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Faulty languages and Liability

"David Botton" <David@Botton.com> wrote:

 
>Using Ada is the first step to solving these problems! 

It is a bit too late for good old Ada.

Now, if the name could be changed, the syntax altered to look like C++
( Yuck ! ) and MS persuaded to market it as Bill .NET, then it might
have a chance :-)

RE: Faulty languages and Liability

[Robert C. Leif]

From: Bob Leif
To: David Botton et al.

I was hoping to find a lawyer to speak on software product liability at
SIGAda 2002. If anyone knows of an attorney, who wishes to become very
rich, this would be a golden chance for that attorney. SIGAda has an
abundance of expert witnesses. In my own field, the FDA regulations
should be stronger than the Ada mandate ever was. Unfortunately, the
FDA's own programmers do not know about Ada. Unfortunately, current
corporate mentality seems much more prone to respond to fear than to
desire to do the job right.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of David Botton
Sent: Saturday, June 15, 2002 7:11 PM
To: comp.lang.ada@ada.eu.org
Subject: Faulty languages and Liability

I have been saying for year the day would come that software authors
would
start to be found liable for their bugs... the time is approaching....

http://story.news.yahoo.com/news?tmpl=story&u=/nm/20020615/tc_nm/bizliab
ilit
y_software_dc_1

<<
Researchers on both sides of the Atlantic say most reported security
incidents are due to software defects that could easily be fixed.
>>

Using Ada is the first step to solving these problems! Now we need to
get
some spokes people to help these lawyers go after faulty software
manufactures for using faulty languages too :-)

David Botton

Re: Faulty languages and Liability

[Hyman Rosen]

Robert C. Leif wrote:
> I was hoping to find a lawyer to speak on software product liability

It's a pretty sad state of affairs when you are reduced to trying
to force people to use Ada at the point of a gun. And of course
that *was* tried with the govenrnment mandate and it failed.

I also point out to you that when your house is broken into or your
car is stolen, you're not going to have any luck suing the makers
of the locks.

If I was sued becuase I didn't use Ada, I would point out to the
jury the results of using Ada on the Ariane 5. You may think it's
unfair, but, ladies and gentlemen of the jury, my worthy opponent
wants my client to use software which demonstrably resulted in
millions of dollars of damage and loss.

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D0C7C0B.5000707@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Robert C. Leif wrote:
>> I was hoping to find a lawyer to speak on software product liability
> 
> It's a pretty sad state of affairs when you are reduced to trying
> to force people to use Ada at the point of a gun. And of course
> that *was* tried with the govenrnment mandate and it failed.

I am not the person you quote, but my interest as a software (including
embedded software) consumer has only to do with how well it works, not
with how that is achieved.  If a vendor wants to provide me software,
be it an Ada compiler or an airbag controller, that is written in the
APL programming language, that is immaterial to me so long as the result
is high reliability.

As a citizen with some knowledge of the field, I think Ada is far
superior to most languages, although languages differences can be
swept away by differences in company attitude.  A company that used
Ada and sought my investment in their stock would find that using
Ada was not my sole criterion, even as regards reliability of
software.

> I also point out to you that when your house is broken into or your
> car is stolen, you're not going to have any luck suing the makers
> of the locks.

LoJack promises a refund if they can't find your car.  The idea of
suing a high-security lock manufacturer if that was the entry point
is not out of the question, but the likelihood of that being the
entry point is low.

> If I was sued becuase I didn't use Ada, I would point out to the
> jury the results of using Ada on the Ariane 5. You may think it's
> unfair, but, ladies and gentlemen of the jury, my worthy opponent
> wants my client to use software which demonstrably resulted in
> millions of dollars of damage and loss.

Certainly you should argue that no other rocket has ever crashed.

But as a I said, there are other criteria besides using Ada,
such as not trying to use the unmodified Ariane 4 software in
the Ariane 5 rocket.

Re: Faulty languages and Liability

[Marin David Condic]

If you brought suit, it wouldn't be with the claim "You didn't use Ada so
you owe me money..." it would be because "You didn't build solid software
and allowed easily detected & corrected bugs to get into the product you
sold me so you owe me money..." Ada expert witnesses would testify "Why yes,
Ada would have detected this error and never let it see the light of day -
and it is readily available technology..." Similarly, other language experts
for languages that are safer than C (or C++?) could be brought up to
testify. "Why yes, Your Honor, everyone in the programming profession
*knows* there are major holes in the C language that are quickly and easily
plugged up by Language X, Language Y and Language Z. If error reduction was
at all important to the defendant, they could have used one of those
languages...."

An argument could be made. Cases could be brought. Suits might actually be
won. Would that *force* people to use Ada? Not at all. It would *force* them
to take responsibility for building crap software & take measures to to
correct that. They *could* do that with C - it would just cost less and be
done faster with Ada.

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


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:Sti2rd9OKA6y@eisner.encompasserve.org...
> In article <3D0C7C0B.5000707@mail.com>, Hyman Rosen <hyrosen@mail.com>
writes:
>
> I am not the person you quote, but my interest as a software (including
> embedded software) consumer has only to do with how well it works, not
> with how that is achieved.  If a vendor wants to provide me software,
> be it an Ada compiler or an airbag controller, that is written in the
> APL programming language, that is immaterial to me so long as the result
> is high reliability.

Re: Faulty languages and Liability

[Hyman Rosen]

Marin David Condic wrote:
> Ada expert witnesses would testify "Why yes, Ada would have
> detected this  error and never let it see the light of day -

That's where I would bring up Ariane 5 :-)

Yes, your honor, but when Ada detects errors, it blows
up the rocket! Maybe this mail program written in C can
be attacked by hackers through buffer overflows, but if
you wrote it in Ada, every time it got a little unhappy,
it would crash and lose all your work! And look, right
there in their manual - it says that in Ada you *have*
to use Unchecked_Conversion and Unchecked_Dealloaction.
See, they're lying about all the checking they claim to do!

Gee, this is fun :-)

Re: Faulty languages and Liability

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0EBE64.2070809@mail.com...
> That's where I would bring up Ariane 5 :-)

So in essence your best defence would be to knowingly drag a red herring
into the argument as well a present false context; thus, knowingly engage in
a deception.  ;)

> Yes, your honor, but when Ada detects errors, it blows
> up the rocket!

Ah yes! the famous compilation error signals the rocket to exploded ;)
Surely you must realise that the errors Ada will not allow to see the light
of day are compilation errors.  I am so far unaware of a compilation error
causing a rocket to exploded.

>Maybe this mail program written in C can
> be attacked by hackers through buffer overflows, but if
> you wrote it in Ada, every time it got a little unhappy,
> it would crash and lose all your work!

Your claim about Ada does not follow (the key phrase is 'every time').  You
can always catch unexpected exceptions and handle them in a graceful manner.

>And look, right
> there in their manual - it says that in Ada you *have*
> to use Unchecked_Conversion and Unchecked_Dealloaction.
> See, they're lying about all the checking they claim to do!
>
> Gee, this is fun :-)

And then we completely degrade into being unreasonable  ... ;)
Being unreasonable is not the best way to try and contest logical and
scientific reasoning.  It may be fun to act unreasonable, but will only
convince me that you are wrong, know it and are trying to deny it anyway ;)

-CRM

-CRM

Re: Faulty languages and Liability

[Hyman Rosen]

Chad R. Meiners wrote:
> And then we completely degrade into being unreasonable  ... ;)

Well, yes, I'm being deliberately silly.

For a real affirmative defense of why I would rather use C++
than Ada,I would pull out the following three textbooks:

_Scientific & Engineering C++_ by Barton & Nackman
_Generative Programming_ by Czarnecki & Eisenecker
_Modern C++ Design_ by Alexandrescu

Re: Faulty languages and Liability

[Wes Groleau]

> For a real affirmative defense of why I would rather use C++
> than Ada,I would pull out the following three textbooks:
> 
> _Scientific & Engineering C++_ by Barton & Nackman
> _Generative Programming_ by Czarnecki & Eisenecker
> _Modern C++ Design_ by Alexandrescu

Do those books actually claim C++ is safer than
anything?  Or should they be subtitled,

  "How to Use C++ and Still Not Get Sued"

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

Re: Faulty languages and Liability

[Robert I. Eachus]

Hyman Rosen wrote:


> ...And look, right
> there in their manual - it says that in Ada you *have*
> to use Unchecked_Conversion and Unchecked_Dealloaction.
> See, they're lying about all the checking they claim to do!
> 
> Gee, this is fun :-)


 From hindsight it is obvious that the names of Unchecked_Conversion and 
Unchecked_Deallocation were mistakes. But what would have been better?

Programmer_Asserts_Conversion_Valid, and 
Programmer_Asserts_this_Object_will_Never_be_Referenced_Again?

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D10BD36.9080102@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:
> Hyman Rosen wrote:
> 
> 
>> ...And look, right
>> there in their manual - it says that in Ada you *have*
>> to use Unchecked_Conversion and Unchecked_Dealloaction.
>> See, they're lying about all the checking they claim to do!
>> 
>> Gee, this is fun :-)
> 
> 
>  From hindsight it is obvious that the names of Unchecked_Conversion and 
> Unchecked_Deallocation were mistakes. But what would have been better?

I _like_ the name "UNCHECKED_whatever".  In fact, when instantiating
those I have taken to using names like UNCHECKED_COPY and UNCHECKED_FREE
to make sure the record of what is unchecked by the compiler is not lost.

Re: Faulty languages and Liability

[Wes Groleau]

> it would crash and lose all your work! And look, right
> there in their manual - it says that in Ada you *have*
> to use Unchecked_Conversion and Unchecked_Dealloaction.

What manual?  I haven't used either of those
in over a year.  So obviously, you don't "have to"
use them.

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

Re: Faulty languages and Liability

[David Botton]

> It's a pretty sad state of affairs when you are reduced to trying
> to force people to use Ada at the point of a gun.

I think the idea here is not to force Ada, but rather to put in to the lime
light when the C/C++/Java code hits the fan.

> If I was sued becuase I didn't use Ada, I would point out to the
> jury the results of using Ada on the Ariane 5.

Ada performed as expected. I would in fact use this to further bolster the
point that negligence is on the developers since _even_ using Ada this can
happen, but having used Ada, if they did the proper testing they _would_
have found the error :-) Something we can not say would have happened in C.

David Botton



"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0C7C0B.5000707@mail.com...
> Robert C. Leif wrote:
> > I was hoping to find a lawyer to speak on software product liability
>
> It's a pretty sad state of affairs when you are reduced to trying
> to force people to use Ada at the point of a gun. And of course
> that *was* tried with the govenrnment mandate and it failed.
>
> I also point out to you that when your house is broken into or your
> car is stolen, you're not going to have any luck suing the makers
> of the locks.
>
> If I was sued becuase I didn't use Ada, I would point out to the
> jury the results of using Ada on the Ariane 5. You may think it's
> unfair, but, ladies and gentlemen of the jury, my worthy opponent
> wants my client to use software which demonstrably resulted in
> millions of dollars of damage and loss.
>

Re: Faulty languages and Liability

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3D0C7C0B.5000707@mail.com>...
> Robert C. Leif wrote:
> > I was hoping to find a lawyer to speak on software product liability
> 
> It's a pretty sad state of affairs when you are reduced to trying
> to force people to use Ada at the point of a gun.

Which of course nobody is trying to do.  However, consider:

It's a pretty sad state of affairs when you are reduced to trying to
force people to use safety glass in automobile windows at the point of
a gun.

It's a pretty sad state of affairs when you are reduced to trying to
force people to manufacture children's sleepwear from nonflamable
materials at the point of a gun.

It's a pretty sad state of affairs when you are reduced to trying to
force people to build earthquake-resistant structures in earthquake
areas at the point of a gun.

Ad infinitum...

So, forcing people to use appropriate tools, techniques and materials,
for public safety and welfare, is not always considered a sad state of
affairs.

> I also point out to you that when your house is broken into or your
> car is stolen, you're not going to have any luck suing the makers
> of the locks.

A better analogy is when your car catches fire while driving down the
road. Lots of people have had -lots- of luck suing auto manufacturers
for faulty products, especially when the fault was caused by using
techniques or materials which are -known- to have fundamental flaws,
and for which there clearly exist better alternatives.
> 
> If I was sued becuase I didn't use Ada,

Nobody is proposing that.

> I would point out to the
> jury the results of using Ada on the Ariane 5. You may think it's
> unfair, but, ladies and gentlemen of the jury, my worthy opponent
> wants my client to use software which demonstrably resulted in
> millions of dollars of damage and loss.

What, exactly, were the "results of using Ada" on the Ariane 5?  I
know you don't like it when people resort to stupid anti-C++ comments
to make a point, so don't resort to stupid anti-Ada comments to make
your point, if you want to be taken seriously on cla.

Mike

Re: Faulty languages and Liability

[Hyman Rosen]

Mike Silva wrote:
> A better analogy is when your car catches fire while driving down the road.

But viruses which take advantage of buffer overflows and such are
like spreading oil on the road to make cars crash. The manufacturer
can very easily argue that the program works fine in normal use, and
that intricately formed attack vectors are not part of that.

It has already been mentioned that there are many other points of
vulnerability than buffer overruns. There is cross-scripting, /tmp
race conditions, symbolic link race conditions, and a host of other
stuff, none of which will be *automatically* caught be using Ada.

So the argument boils down to the usual about Ada being better,
but that doesn't really bring product liability into it.

>>If I was sued becuase I didn't use Ada,
> Nobody is proposing that.

Sure they are, when an Ada advocate starts suggesting product liability
lawsuits.

> What, exactly, were the "results of using Ada" on the Ariane 5?  I
> know you don't like it when people resort to stupid anti-C++ comments
> to make a point, so don't resort to stupid anti-Ada comments to make
> your point, if you want to be taken seriously on cla.

I wouldn't resort to stupid anti-Ada comments on c.l.a, but if someone
was trying to use lawsuits to force me to abandon the one true way and
start using Ada instead, you can be sure that I would use every method
at my disposal to fight that, including launching unfair attacks against
Ada. I would resort to stupid anti-Ada comments with the jury.

The point of Ariane 5 is that the rocket blew up even though the software
was written in Ada. This very much weakens the arguments that could be
made that one should have used Ada instead of [lang], since there is a
spectacular failure which demonstrates that writing in Ada is no panacea.
So we just get back to the usual arguments about why one language is
better than another, but there isn't much there for liability suits to
claim that one should have used a different language.

Re: Faulty languages and Liability

[David Botton]

I don't think any one is advocating lawsuits, just mentioning that if there
should be a case, the choice of tools used to build software should be put
in question. Ada being an example of a better safer tool that is readily
available and frequently not chosen for non technical reasons.

David Botton

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0D31D2.2000104@mail.com...
> Sure they are, when an Ada advocate starts suggesting product liability
> lawsuits.

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <ugqo9r629htifc@corp.supernews.com>, "David Botton" <David@Botton.com> writes:
> I don't think any one is advocating lawsuits, just mentioning that if there
> should be a case, the choice of tools used to build software should be put
> in question. Ada being an example of a better safer tool that is readily
> available and frequently not chosen for non technical reasons.
> 
> David Botton
> 
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:3D0D31D2.2000104@mail.com...
>> Sure they are, when an Ada advocate starts suggesting product liability
>> lawsuits.

I would advocate lawsuits for product liability that involves software
causing significant harm like the Therac medical machinery case.  There
have certainly been civil lawsuits over whether a vendor's Bill-of-Materials
software did or did not perform up to specification.

If I were on a jury regarding a faulty concrete pour, I would certainly
want to take into account the degree to which checking was involved in the
use of the concrete, and I would be impressed if there were concrete that
would turn blue if improperly cured.

Re: Faulty languages and Liability

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3D0D31D2.2000104@mail.com>...
> Mike Silva wrote:
> > A better analogy is when your car catches fire while driving down the road.
> 
> But viruses which take advantage of buffer overflows and such are
> like spreading oil on the road to make cars crash. The manufacturer
> can very easily argue that the program works fine in normal use, and
> that intricately formed attack vectors are not part of that.

The story, and "The Story", are about much more than buffer overflows
-- it's about faulty software in general.  If there were tire
technology that could allow safe driving in oil slicks, and oil slicks
were common on the road, then yes, using 30-year-old technology that
couldn't handle the problem sounds like gross negligence to me.

> 
> It has already been mentioned that there are many other points of
> vulnerability than buffer overruns. There is cross-scripting, /tmp
> race conditions, symbolic link race conditions, and a host of other
> stuff, none of which will be *automatically* caught be using Ada.

Automobiles may crash if somebody throws a brick through the window,
or if they hit a patch of ice.  Every auto is susceptible to such
problems, because the technology does not exist or is not affordable
to prevent them.  However, when cars burn up because they use faulty
fuel hose when there exists a correct fuel hose then that's quite
possibly negligence.
> 
> So the argument boils down to the usual about Ada being better,
> but that doesn't really bring product liability into it.
> 
> >>If I was sued becuase I didn't use Ada,
> > Nobody is proposing that.
> 
> Sure they are, when an Ada advocate starts suggesting product liability
> lawsuits.

It's not about using Ada, it's about -not- using the most faulty tools
in the toolbox, which are known by one and all to be faulty tools
relative to other commonly available tools.
> 
> > What, exactly, were the "results of using Ada" on the Ariane 5?  I
> > know you don't like it when people resort to stupid anti-C++ comments
> > to make a point, so don't resort to stupid anti-Ada comments to make
> > your point, if you want to be taken seriously on cla.
> 
> I wouldn't resort to stupid anti-Ada comments on c.l.a, but if someone
> was trying to use lawsuits to force me to abandon the one true way and
> start using Ada instead...

It's not about Ada, it's about using reasonable, well-known tools and
techniques that are better than those being used.

> you can be sure that I would use every method
> at my disposal to fight that, including launching unfair attacks against
> Ada. I would resort to stupid anti-Ada comments with the jury.
> 
> The point of Ariane 5 is that the rocket blew up even though the software
> was written in Ada. This very much weakens the arguments that could be
> made that one should have used Ada instead of [lang], since there is a
> spectacular failure which demonstrates that writing in Ada is no panacea.
> So we just get back to the usual arguments about why one language is
> better than another, but there isn't much there for liability suits to
> claim that one should have used a different language.

That's a straw man.  Nobody ever, ever claims that a project using
software written in "X" can never, ever have a failure traceable to
proper or improper operation of the "X" software, anymore than
building aircraft with aerospace-rated bolts will guarantee that a
plane will never have a structural failure.  The problem today is that
far too many software houses are putting cheap hardware store bolts in
their planes and saying that they can't do any better.

It's not about perfect software, it's about negligence in knowingly
using inadequate tools and techniques when better ones have existed
for decades.

Mike

Re: Faulty languages and Liability

[AG]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0D31D2.2000104@mail.com...

>
> The point of Ariane 5 is that the rocket blew up even though the software
> was written in Ada. This very much weakens the arguments that could be
> made that one should have used Ada instead of [lang], since there is a
> spectacular failure which demonstrates that writing in Ada is no panacea.
> So we just get back to the usual arguments about why one language is
> better than another, but there isn't much there for liability suits to
> claim that one should have used a different language.
>

Well, to continue the car similarity from another post - sure, any type of
a car tyre may and will blow up now and then. The question is - was it
faulty to beging with?  Was there a better alternative? Did the manufacurer
take a due care? As a number of recent successful law-suits show, the legal
opinion seems to be not in your favour...

Re: Faulty languages and Liability

[Hyman Rosen]

AG wrote:
> Well, to continue the car similarity from another post - sure, any type of
> a car tyre may and will blow up now and then. The question is - was it
> faulty to beging with?  Was there a better alternative? Did the manufacurer
> take a due care? As a number of recent successful law-suits show, the legal
> opinion seems to be not in your favour...

But hacker attacks are more like someone slashing tires,
or perhaps taking a car meant for normal highway use and
driving it for thousands of miles over rough terrain.

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D0DE268.2000207@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> AG wrote:
>> Well, to continue the car similarity from another post - sure, any type of
>> a car tyre may and will blow up now and then. The question is - was it
>> faulty to beging with?  Was there a better alternative? Did the manufacurer
>> take a due care? As a number of recent successful law-suits show, the legal
>> opinion seems to be not in your favour...
> 
> But hacker attacks are more like someone slashing tires,
> or perhaps taking a car meant for normal highway use and
> driving it for thousands of miles over rough terrain.

Many hacker attacks are akin to thieves hot-wiring a car and taking it
for a joy ride.   I believe the US has standards regarding how good the
locks must be on cars.  I know my state has a law forbidding the motorist
to leave the keys in the ignition.

RE: Faulty languages and Liability

[Robert C. Leif]

From: Bob Leif
To: Hyman Rosen,
The Ariane 5 was a design defect. The code produced an error exactly as
specified. I would consider the actions of some individuals on the
Ariane 5 project to be negligence. They specified that code be reused
without checking if it still modeled the physics of the system. However,
this is a question of French law of which I know very little. 

US Government mandates are usually not as effective as legal actions.
The employees of US enforcement agencies do not work on commission.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Hyman Rosen
Sent: Sunday, June 16, 2002 4:53 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Faulty languages and Liability

Robert C. Leif wrote:
> I was hoping to find a lawyer to speak on software product liability

It's a pretty sad state of affairs when you are reduced to trying
to force people to use Ada at the point of a gun. And of course
that *was* tried with the govenrnment mandate and it failed.

I also point out to you that when your house is broken into or your
car is stolen, you're not going to have any luck suing the makers
of the locks.

If I was sued becuase I didn't use Ada, I would point out to the
jury the results of using Ada on the Ariane 5. You may think it's
unfair, but, ladies and gentlemen of the jury, my worthy opponent
wants my client to use software which demonstrably resulted in
millions of dollars of damage and loss.

Re: Faulty languages and Liability

[Hyman Rosen]

Robert C. Leif wrote:
> The Ariane 5 was a design defect.
> The code produced an error exactly as specified.

Yes, I know this. I have been here for a while, after all.

My argument is this. Someone is proposing to haul me into
court because I use C++ instead of Ada. I'm going to say
look at the Ariane 5 - it used Ada and it blew up. They'll
respond just like you did above. And I'll say that they are
supporting my point - it's design and specification and
engineering errors that cause problems, not the choice of
programming language, and I can do just as well with C++
as I can with Ada.

Then we'll start with the finger pointing - "But Ada does
this and C++ doesn't" = "But C++ does this and Ada doesn't".
And we'll just conclude that it's up to the people who make
software to decide what to use to make it.

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D0DE5E2.5010904@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Robert C. Leif wrote:
>> The Ariane 5 was a design defect.
>> The code produced an error exactly as specified.
> 
> Yes, I know this. I have been here for a while, after all.
> 
> My argument is this. Someone is proposing to haul me into
> court because I use C++ instead of Ada.

No rational person is going to haul you into court because you use C++.
Somebody who hauls you into court because your software blew up may
bring up the issue of language as _one_ of a series of issues regarding
the reliability of your development process.  I presume that if they
say you didn't use Ada, you will also didn't use plain C.  Presumably
you will also show that you were not programming in C using a compiler
that happened to be a C++ compiler.

> Then we'll start with the finger pointing - "But Ada does
> this and C++ doesn't" = "But C++ does this and Ada doesn't".
> And we'll just conclude that it's up to the people who make
> software to decide what to use to make it.

If it got to that point yes.  But if I were on the jury you would be in
deep trouble if you said you used C++ because Microsoft endorsed it :-)

There is a serious question in my mind whether everyone using C* has
done so based on thorough reasoning.  Some would be much better off
implementing their project in Basic.

Re: Faulty languages and Liability

[Hyman Rosen]

Larry Kilgallen wrote:
> There is a serious question in my mind whether everyone using C* has
> done so based on thorough reasoning.

I can't speak for anyone else, but I use C++ because I love it.
I am at my current job because I answered an ad which was looking
for expert C++ programmers, and it sounded (and is) exactly like
what I wanted. I find the combination of multiple inheritance,
virtual functions, and automatically instantiated templates to
result in remarkably concise, expressive, efficient, and typesafe
code which is moreover a lot of fun to write. It more than makes
up for the warped C-legacy syntax.

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D0DF19E.5010805@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Larry Kilgallen wrote:
>> There is a serious question in my mind whether everyone using C* has
>> done so based on thorough reasoning.
> 
> I can't speak for anyone else, but I use C++ because I love it.

Nobody who reads your posts doubts that about you.  I am sure there are
others in a similar position.  But I suspect there are still others with
much less basis for their decision.  Even some who make the decision with
_no_ technical background (managers).

> I am at my current job because I answered an ad which was looking
> for expert C++ programmers, and it sounded (and is) exactly like
> what I wanted. I find the combination of multiple inheritance,
> virtual functions, and automatically instantiated templates to
> result in remarkably concise, expressive, efficient, and typesafe
> code which is moreover a lot of fun to write. It more than makes
> up for the warped C-legacy syntax.

C++ is bound to be less attractive to those of us not from a C background.

Re: Faulty languages and Liability

[Marin David Condic]

Now I'm curious. You love C++. You work with C++. Yet you're regularly here
on C.L.A? Do you have some other sort of interest in Ada? Or is it that you
just want to defend C++ from some of its more ardent detractors? :-)

I'm not being critical - just curious as to what brings you here?

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


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0DF19E.5010805@mail.com...
>
> I can't speak for anyone else, but I use C++ because I love it.
> I am at my current job because I answered an ad which was looking
> for expert C++ programmers, and it sounded (and is) exactly like
> what I wanted. I find the combination of multiple inheritance,
> virtual functions, and automatically instantiated templates to
> result in remarkably concise, expressive, efficient, and typesafe
> code which is moreover a lot of fun to write. It more than makes
> up for the warped C-legacy syntax.
>

Re: Faulty languages and Liability

[Hyman Rosen]

Marin David Condic wrote:
> Now I'm curious. You love C++. You work with C++. Yet you're regularly here
> on C.L.A? Do you have some other sort of interest in Ada? Or is it that you
> just want to defend C++ from some of its more ardent detractors? :-)
> 
> I'm not being critical - just curious as to what brings you here?

I consider myself somewhat of a programming language hobbyist.
I hang out here (as well as on comp.std.c++ and comp.lang.c++.moderated)
because I find the level of discourse, and of the participants, to be high
(yourself included). I don't dislike Ada at all, and I find it entertaining
to defend C++ against unfair claims here, as well as to post "Ada does it
much better this way" on the C++ groups.

There's also a certain amount of silver bulletness here that's fun to
puncture :-)

I find it very instructive, as I learn more about Ada, to try to figure
out the essential differences between Ada and C++ and how those differences
affect the expressiveness of the language. For example, I recently had an
epiphany regarding the difference between Ada's explicit generic instantiations
and C++'s automatic template instantiations. It's why you can't do units easily
in Ada, and why local variables can't be template parameters in C++.

And as C++ moves to adopt concurrent programming (which is almost certain to
happen in the next revision), I'm hoping (and urging) that the people involved
understand how Ada does it, so we don't wind up with a stupid hodgepodge. That
doesn't mean that it should look the same in C++, but they should understand
why certain decisions were made.

Re: Faulty languages and Liability

[Marin David Condic]

Well, there's certainly a lot of good reasons to learn about and understand
"foreign" languages. While I've been an Ada programmer for a long time, I am
currently employed doing C and C++ and in the past have used a variety of
fairly obscure languages such as Jovial for production work. There's much to
be learned, even if your favorite language doesn't change.

I don't personally have any problem with C/C++ bashing so long as the
criticisms are fair and that one always remembers that there are good
reasons - often beyond the technical - why other languages are used. But its
nice to have you here to defend C++, so keep it up. (Otherwise, where's the
sport in it? :-)

As for automatic template instantiations, I know enough about them to see
that they have potential problems to cause things to happen behind one's
back - which is one of the common complaints here about C/C++ in general.
(Type conversions go on without one's knowledge & consent being a common
source of errors.) However, I can see your point about how it would make
unit conversions less painful. Call it a difference in priorities. Ada wants
to be sure that nothing happens without the programmer having deliberately
decided to do it. Good for safety - bad for convenience. (automatic
instantiation might have made I/O in Ada a whole lot less painful!) C++
gives you convenience - but you sacrifice safety & can start asking for some
really hard to detect bugs. (Probably it creates testing difficulties as
well if you have really stringent test requirements.)Which is better? It
depends on what's important to you. I'd obviously opt for Ada because over
the years, I've grown to appreciate the safety & bug reduction
characteristics.

Anyway, I'm glad I understand what brings you here. Maybe we'll succeed in
making a convert out of you. :-) At least there's likely to be a "Don't
dismiss Ada so casually..." voice in the C++ community.

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


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0EC296.8070504@mail.com...
>
> I consider myself somewhat of a programming language hobbyist.
> I hang out here (as well as on comp.std.c++ and comp.lang.c++.moderated)
> because I find the level of discourse, and of the participants, to be high
> (yourself included). I don't dislike Ada at all, and I find it
entertaining
> to defend C++ against unfair claims here, as well as to post "Ada does it
> much better this way" on the C++ groups.
>
> There's also a certain amount of silver bulletness here that's fun to
> puncture :-)
>
> I find it very instructive, as I learn more about Ada, to try to figure
> out the essential differences between Ada and C++ and how those
differences
> affect the expressiveness of the language. For example, I recently had an
> epiphany regarding the difference between Ada's explicit generic
instantiations
> and C++'s automatic template instantiations. It's why you can't do units
easily
> in Ada, and why local variables can't be template parameters in C++.
>
> And as C++ moves to adopt concurrent programming (which is almost certain
to
> happen in the next revision), I'm hoping (and urging) that the people
involved
> understand how Ada does it, so we don't wind up with a stupid hodgepodge.
That
> doesn't mean that it should look the same in C++, but they should
understand
> why certain decisions were made.
>

Re: Faulty languages and Liability

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Larry Kilgallen wrote:
> > There is a serious question in my mind whether everyone using C* has
> > done so based on thorough reasoning.
> 
> I can't speak for anyone else, but I use C++ because I love it.

If I were a lawyer sueing somebody for using C++ (which I admit is kind
of silly), I would *love* to hear that statement given under oath! ;-)

Sort of like a civil engineer who builds a bridge that falls down
saying, "I built it out of inferior steel because I love that kind
of steel."  Or the second of the Three Pigs claiming to "love" building
houses out of sticks.

> I am at my current job because I answered an ad which was looking
> for expert C++ programmers, and it sounded (and is) exactly like
> what I wanted. I find the combination of multiple inheritance,
> virtual functions, and automatically instantiated templates to
> result in remarkably concise, expressive, efficient, and typesafe
> code which is moreover a lot of fun to write. It more than makes
> up for the warped C-legacy syntax.

- Bob

Re: Faulty languages and Liability

[John Kern]

Larry Kilgallen wrote:

> 
> No rational person is going to haul you into court because you use C++.
> Somebody who hauls you into court because your software blew up may
> bring up the issue of language as _one_ of a series of issues regarding
> the reliability of your development process.  I presume that if they
> say you didn't use Ada, you will also didn't use plain C.  Presumably
> you will also show that you were not programming in C using a compiler
> that happened to be a C++ compiler.
> 
I could see being attacked for not using a "validated" compiler.  Are
there any validated C or C++ compilers?  I wouldn't know.  Are the
languages standardized enough to allow a validation suite?

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D0F91D3.87CDBDF7@NOSPAM.visteon.com>, John Kern <jkern3@NOSPAM.visteon.com> writes:
> 
> 
> Larry Kilgallen wrote:
> 
>> 
>> No rational person is going to haul you into court because you use C++.
>> Somebody who hauls you into court because your software blew up may
>> bring up the issue of language as _one_ of a series of issues regarding
>> the reliability of your development process.  I presume that if they
>> say you didn't use Ada, you will also didn't use plain C.  Presumably
>> you will also show that you were not programming in C using a compiler
>> that happened to be a C++ compiler.
>> 
> I could see being attacked for not using a "validated" compiler.  Are
> there any validated C or C++ compilers?  I wouldn't know.  Are the
> languages standardized enough to allow a validation suite?

In a real court case, issues of compiler validation would likely not
have any bearing unless it can be shown the compiler in question made
an error that would have been caught by a validated compiler.

Re: Faulty languages and Liability

[John Kern]

Larry Kilgallen wrote:

> In a real court case, issues of compiler validation would likely not
> have any bearing unless it can be shown the compiler in question made
> an error that would have been caught by a validated compiler.


I once heard from one of my professors that they preferred to take
testimony from only engineers certified Professional Engineers.  If I
were on a jury and someone told me that they used a "Validated"
compiler, I think I would think more highly of it than otherwise, even
if I didn't know what it meant.

Wouldn't your argument also hold that if a language in question allowed
an error that would have been caught by another language?

If a field of endeavor establishes an industry "best practice" say for
eliminating errors in embedded software, (say MISRA C coding standards),
I think a supplier is at risk for deviating.  If we could only prove
that Ada programs are intrinsically safer than C programs.

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D10A7A0.376A5F45@NOSPAM.visteon.com>, John Kern <jkern3@NOSPAM.visteon.com> writes:
> Larry Kilgallen wrote:
> 
>> In a real court case, issues of compiler validation would likely not
>> have any bearing unless it can be shown the compiler in question made
>> an error that would have been caught by a validated compiler.
> 
> 
> I once heard from one of my professors that they preferred to take
> testimony from only engineers certified Professional Engineers.  If I
> were on a jury and someone told me that they used a "Validated"
> compiler, I think I would think more highly of it than otherwise, even
> if I didn't know what it meant.

Competent opposing counsel would make sure you knew what that meant.

> Wouldn't your argument also hold that if a language in question allowed
> an error that would have been caught by another language?

Certainly if the error in question was the cause of the problem.
Not if management running the software on the wrong hardware (rocket)
was the cause of the problem.

> If a field of endeavor establishes an industry "best practice" say for
> eliminating errors in embedded software, (say MISRA C coding standards),
> I think a supplier is at risk for deviating.

Perhaps in an Enron-style trial for gross misconduct, but not for
a trial about a particular failure incident.

Re: Faulty languages and Liability

[Marin David Condic]

I wouldn't imagine a court saying otherwise. What a court *might* say is
"You built lousy software knowing full well and good that techniques and
tools existed to catch/fix the errors that were brought before this
court..." Go ahead and pick whatever tools you like. If the tools you pick
don't catch the errors for you (knowing that other tools do), then you ought
to institute some other processes by which you can catch them. Now its up to
you to decide what technology you want to employ.

As a side question: Does anybody know of a list of typical C/C++ errors that
can't happen in Ada? It might be useful to do a side-by-side comparison.
(This kind of error is common in C... - This error can't happen in Ada
because...) I know Lucent had a study of common C errors & that a good
number of them couldn't happen in Ada. (Read the report years ago). Of
course the report concluded "we will institute coding standards and code
reviews..." rather than "we'll use a language that will catch these things
automatically..." - but it wasn't the point of the study to foament a
revolution.

I just think it would be instructive to have a web page comparing C/C++
errors against "Can't happen in Ada" or "Unlikely to happen in Ada
because.."

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


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0DE5E2.5010904@mail.com...
> And we'll just conclude that it's up to the people who make
> software to decide what to use to make it.
>

Re: Faulty languages and Liability

[Wes Groleau]

> As a side question: Does anybody know of a list of typical C/C++ errors that
> can't happen in Ada? It might be useful to do a side-by-side comparison.

I read the first half of "C Traps and Pitfalls"
Almost all of them either could not happen in Ada
or would only happen if you knowingly forced them to.

The best one was more than a page discussing the subtle
differences between various long strings consisting
almost entirely of asterisks and parens!!

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

Re: Faulty languages and Liability

[Marin David Condic]

I might have to look that reference up. I just think it would be instructive
to do some version of "Common C/C++ Error" vs "Can't Happen In Ada Because"
and have that on a web page somewhere.

As for the complex asterisk/paren/ampersand strings of C code - I've seen
that stuff and it usually fills me with an urge to deficate. That a) someone
thought it was a good idea to write it and b) they are allowed near a
computer keyboard and (probably) allowed to vote and drive cars really
scares me. :-) (But if you dare criticize such obfuscations you usually get
the "Well if you were a *COMPETENT* C programmer, it would be intuitively
obvious...")

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


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3D0F8A25.EB1FA77B@despammed.com...
>
> I read the first half of "C Traps and Pitfalls"
> Almost all of them either could not happen in Ada
> or would only happen if you knowingly forced them to.
>
> The best one was more than a page discussing the subtle
> differences between various long strings consisting
> almost entirely of asterisks and parens!!
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Faulty languages and Liability

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3D0DE5E2.5010904@mail.com>...

> ...it's design and specification and
> engineering errors that cause problems, not the choice of
> programming language, and I can do just as well with C++
> as I can with Ada.

So then you're asserting that choice of language has absolutely no
effect on software quality?  And you're also asserting that this is
the consensus opinion in the industry?

Coincidentally, from the currently-being-discussed Hoare paper of 1980
(discussing such security checking as array bounds checking):
"In any respectible branch of engineering, failure to observe such
elementary precautions would have long been against the law."

So, given the well-known falible nature of human programmers, if one
has the choice between well-known tools which perform many such checks
automatically, and tools which do not perform such checks
automatically, and if an organization then uses tools of the second
type which contribute to a major software failure, has due diligence
been used?

Here's another gem from the Hoare paper:
"An unreliable programming language generating unreliable programs
constitutes a far greater risk to our environment and to our society
than unsafe cars, toxic pesticides, or accidents at nuclear power
stations."

So I infer that Hoare, at least, does believe that choice of language
has an effect on software quality.

Mike

Re: Faulty languages and Liability

[Hyman Rosen]

Mike Silva wrote:
> Here's another gem from the Hoare paper:
> "An unreliable programming language generating unreliable programs
> constitutes a far greater risk to our environment and to our society
> than unsafe cars, toxic pesticides, or accidents at nuclear power
> stations."

That paper was published in 1980.

The Firestone tire recall happened in 2000.
The Bhopal accident happened in 1984.
The Chernobyl accident happened in 1986.

It appears that he is wrong.

Re: Faulty languages and Liability

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3D0E48C4.2020005@mail.com>...
> Mike Silva wrote:
> > Here's another gem from the Hoare paper:
> > "An unreliable programming language generating unreliable programs
> > constitutes a far greater risk to our environment and to our society
> > than unsafe cars, toxic pesticides, or accidents at nuclear power
> > stations."
> 
> That paper was published in 1980.
> 
> The Firestone tire recall happened in 2000.
> The Bhopal accident happened in 1984.
> The Chernobyl accident happened in 1986.
> 
> It appears that he is wrong.

Maybe yes, maybe no -- with software-based systems continuing to grow
exponentially, don't assume the question is answered yet...

Re: Faulty languages and Liability

[Hyman Rosen]

Mike Silva wrote:
> Maybe yes, maybe no -- with software-based systems continuing to grow
> exponentially, don't assume the question is answered yet...

Yup. For instance, check out <http://msnbc.com/news/768401.asp>.

Re: Faulty languages and Liability

[chris.danx]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0F4DBB.3010901@mail.com...
> Mike Silva wrote:
> > Maybe yes, maybe no -- with software-based systems continuing to grow
> > exponentially, don't assume the question is answered yet...
>
> Yup. For instance, check out <http://msnbc.com/news/768401.asp>.


That article blaims coders and buffer overflow errors for the Ariane 5
fiasco.  I thought it was a management issue to reuse of a software module
which worked ok for the Ariane 4?  That data valid for the Arian 5 was
invalid data for Arian 4 (due to their differing flight characteristics),
and that the module perfomed as it should have if it were in an Arian 4?

i.e. the software worked ok, it was just in the wrong rocket.


Perhaps someone should tell them.


Chris

Re: Faulty languages and Liability

[Marin David Condic]

Yup. The article got it dead wrong - which leads one to wonder who their
source is for this information. If it was a "systematic software design
error" as they claim, I'd find that to be at best "questionable". But it was
most certainly NOT a "buffer overflow" - as they claim. In the opinions of
many, it wasn't a "design error" at all - the software functioned 100%
according to its design. It was a "management error" to change the
requirements and then never test the software to be sure it met the new
ones.

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


"chris.danx" <spamoff.danx@ntlworld.com> wrote in message
news:2JIP8.6961$AZ6.519787@news6-win.server.ntlworld.com...
>
>
> That article blaims coders and buffer overflow errors for the Ariane 5
> fiasco.  I thought it was a management issue to reuse of a software module
> which worked ok for the Ariane 4?  That data valid for the Arian 5 was
> invalid data for Arian 4 (due to their differing flight characteristics),
> and that the module perfomed as it should have if it were in an Arian 4?
>
> i.e. the software worked ok, it was just in the wrong rocket.
>
>
> Perhaps someone should tell them.
>
>
> Chris
>
>

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D0F4DBB.3010901@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Mike Silva wrote:
>> Maybe yes, maybe no -- with software-based systems continuing to grow
>> exponentially, don't assume the question is answered yet...
> 
> Yup. For instance, check out <http://msnbc.com/news/768401.asp>.

Reading that on my web browser, I was not overly surprised to see:

" As Microsofts online Knowledge Base
blandly explained, the special backup floppy disks created by Windows XP Home do
not work with Windows XP Home. 

A.acollink { font-size: 10px/11px; font-family:arial;
TEXT-DECORATION:NONE; } A.acollink:hover { color: cc0000 } a.yblnk
{text-decoration:none;color:000099;font-family:arial;font-size:13px;}
a:visited.yblnk {color:3366cc;} a:active.yblnk {color:000099;} a:hover.yblnk
{color:cc0000;} .ybText {font-family:arial;font-size:13px;} .ybBulRed
{color:cc0000;font-family:verdana;font-size:14px;vertical-align:top;width:10px;}
.ybBulOly
{color:ff6600;font-family:verdana;font-size:14px;vertical-align:top;width:10px;}  "

Re: Faulty languages and Liability

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3D0DE5E2.5010904@mail.com>...

> ...it's design and specification and
> engineering errors that cause problems, not the choice of
> programming language, and I can do just as well with C++
> as I can with Ada.

So then you're asserting that choice of language has absolutely no
effect on software quality?  And you're also asserting that this is
the consensus opinion in the industry?

Coincidentally, from the currently-being-discussed Hoare paper of 1980
(discussing such security checking as array bounds checking):
"In any respectible branch of engineering, failure to observe such
elementary precautions would have long been against the law."

So, given the well-known falible nature of human programmers, if one
has the choice between well-known tools which perform many such checks
automatically, and tools which do not perform such checks
automatically, and if a falible programmer then uses tools of the
second type which contribute to a major software failure, has due
diligence been used?

Mike

Re: Faulty languages and Liability

[Hyman Rosen]

Mike Silva wrote:
> So then you're asserting that choice of language has absolutely no
> effect on software quality?

Not no effect, but not enough of an effect to justify requiring
under pain of lawsuit that one be used and that one not be used.

> And you're also asserting that this is
> the consensus opinion in the industry?

Nope. That's why so many places adopted Java. They just got
tired of the risks of using Unchecked_Deallocation in their
Ada code.

> Coincidentally, from the currently-being-discussed Hoare paper of 1980
> (discussing such security checking as array bounds checking):
> "In any respectible branch of engineering, failure to observe such
> elementary precautions would have long been against the law."

I wonder why Ada compilers allow these checks to be turned off, then?

> So, given the well-known falible nature of human programmers, if one
> has the choice between well-known tools which perform many such checks
> automatically, and tools which do not perform such checks
> automatically, and if a falible programmer then uses tools of the
> second type which contribute to a major software failure, has due
> diligence been used?

Perhaps not in hiring that programmer. The tools in question are not
equivalent in other aspects than safety, which is why the safe ones
are not always chosen.

Re: Faulty languages and Liability

[Marin David Condic]

Suppose the case goes like this:

You purchased software that failed in some way and caused you harm.

You discover that the reason for that failure (and your subsequent damage)
was that the program had a careless and unchecked array reference that
allowed an index to go out of bounds.

You argue in court that array index out of bounds errors are classic errors
discussed in all forms of computer science textbooks and that they are so
well known and infamous that most modern programming languages automatically
include runtime checks in them to catch this kind of error. Since the error
type is so well known and so obviously a problem, one would expect that a
*competent* programmer and a *responsible* company would have exercised due
dilligence and either a) used a language that checked for this common and
well publicized risk or b) maintained coding standards that would have
insured that all array references were manually bounds checked if the
language didn't provide for it.

Sounds to me like a case that might be made. In the same way that we would
hold a company liable for constructing a catwalk without guardrails, we
could hold a company liable for constructing software without array bounds
checks. How is this different? All the same arguments made against bounds
checks could be applied to guard rails. (Inefficient, costs too much, not
necessary, etc.) I doubt the courts would dictate the tools to use to build
the guard rails, but they might still insist on you're putting them up.

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


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0E461A.8050207@mail.com...
>
> > So, given the well-known falible nature of human programmers, if one
> > has the choice between well-known tools which perform many such checks
> > automatically, and tools which do not perform such checks
> > automatically, and if a falible programmer then uses tools of the
> > second type which contribute to a major software failure, has due
> > diligence been used?
>
> Perhaps not in hiring that programmer. The tools in question are not
> equivalent in other aspects than safety, which is why the safe ones
> are not always chosen.
>

Re: Faulty languages and Liability

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0E461A.8050207@mail.com...
> I wonder why Ada compilers allow these checks to be turned off, then?

Because design constraints might require it.  Honestly, Hyman, surely you
recognize that a language with automatic checking that may be explicitly
turn off is safer than a language in which programmers must implement checks
themselves.

-CRM

Re: Faulty languages and Liability

[Hyman Rosen]

Chad R. Meiners wrote:
> Because design constraints might require it.  Honestly, Hyman, surely you
> recognize that a language with automatic checking that may be explicitly
> turn off is safer than a language in which programmers must implement checks
> themselves.

If it's "criminal" to use a language without bounds checking, why would it
be OK to remove those checks? It's like removing the safety guard from the
chainsaw as soon as the factory finishes testing it, so that the customer
doesn't get to use it.

Re: Faulty languages and Liability

[Chad R. Meiners]

It is okay to remove a check if you prove that the condition being checked
for can never happen.  Anyway I don't think it would be criminal to use a
language without bounds checking; it would only be negligent.  In some cases
this negligence would be criminal.

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0EBC9F.9040104@mail.com...
> If it's "criminal" to use a language without bounds checking, why would it
> be OK to remove those checks? It's like removing the safety guard from the
> chainsaw as soon as the factory finishes testing it, so that the customer
> doesn't get to use it.
>

Re: Faulty languages and Liability

[Marin David Condic]

It would be neither criminal nor negligent to use a language without bounds
checking. It *might* be negligent to use one without bounds checking and not
manually insert the checks or otherwise certify via analysis or test that
the bounds won't be exceeded. It is - or ought to be - very well understood
in the industry that failure to check array bounds (via language, manual
code, analysis or test) is a major source of easily prevented errors. You
don't *have* to use Ada - it would just be cheaper to use a language that
performed commonly accepted compile and/or runtime checks.

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


"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:aendq2$2onk$1@msunews.cl.msu.edu...
> It is okay to remove a check if you prove that the condition being checked
> for can never happen.  Anyway I don't think it would be criminal to use a
> language without bounds checking; it would only be negligent.  In some
cases
> this negligence would be criminal.
>

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <aenfam$oc3$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> It would be neither criminal nor negligent to use a language without bounds
> checking. It *might* be negligent to use one without bounds checking and not
> manually insert the checks or otherwise certify via analysis or test that
> the bounds won't be exceeded. It is - or ought to be - very well understood
> in the industry that failure to check array bounds (via language, manual
> code, analysis or test) is a major source of easily prevented errors. You
> don't *have* to use Ada - it would just be cheaper to use a language that
> performed commonly accepted compile and/or runtime checks.

We cannot prejudge what would be cheaper in all situations.
Some programs make only minor use of arrays.

Re: Faulty languages and Liability

[Marin David Condic]

Well, O.K. Fair enough. But I wasn't really thinking only of arrays - or
even only of Ada. There are *lots* of common programming errors that could
be checked and detected statically or dynamically that currently aren't
because programs are built in C/C++ and checking those errors is not
automagic. Things like parameter passing to subroutines or the
referencing/dereferencing of things by address. Many of these things can be
fixed by Ada or other languages that do better type checking and such. You
can do it manually by inserting your own code and/or code reviews and/or
rigorous testing, etc, etc, etc. All that costs more than having the
compiler do it for you. To *that* extent - its always cheaper. There may be
other factors on a project that make some other less safe language less
expensive to use - even if you have to add in all the costs of insuring
minimal safety.

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


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:kvL0$8CK4ybO@eisner.encompasserve.org...
>
> We cannot prejudge what would be cheaper in all situations.
> Some programs make only minor use of arrays.

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <aeq407$lvr$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Well, O.K. Fair enough. But I wasn't really thinking only of arrays - or
> even only of Ada. There are *lots* of common programming errors that could
> be checked and detected statically or dynamically that currently aren't
> because programs are built in C/C++ and checking those errors is not
> automagic. Things like parameter passing to subroutines or the
> referencing/dereferencing of things by address. Many of these things can be
> fixed by Ada or other languages that do better type checking and such. You
> can do it manually by inserting your own code and/or code reviews and/or
> rigorous testing, etc, etc, etc. All that costs more than having the
> compiler do it for you. To *that* extent - its always cheaper. There may be
> other factors on a project that make some other less safe language less
> expensive to use - even if you have to add in all the costs of insuring
> minimal safety.

There may be other factors that make some other language more strategic
to use.  If the project is itself a compiler, writing it in the target
language guarantees some degree of inhouse testing.

Re: Faulty languages and Liability

[Wes Groleau]

> There may be other factors that make some other language more strategic
> to use.  If the project is itself a compiler, writing it in the target
> language guarantees some degree of inhouse testing.

That could backfire, if too many people think that
testing the compiler on itself is adequate.

An application program may do things that don't happen
often in a compiler.

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

Re: Faulty languages and Liability

[Larry Kilgallen]

In article <3D12087D.A3696BB9@despammed.com>, Wes Groleau <wesgroleau@despammed.com> writes:
> 
> 
>> There may be other factors that make some other language more strategic
>> to use.  If the project is itself a compiler, writing it in the target
>> language guarantees some degree of inhouse testing.
> 
> That could backfire, if too many people think that
> testing the compiler on itself is adequate.
> 
> An application program may do things that don't happen
> often in a compiler.

Yes, it is a tricky decision how to handle this, requiring an
extraordinary ability to measure the nature of the organization :-)

Re: Faulty languages and Liability

[Hyman Rosen]

Marin David Condic wrote:
 > Things like parameter passing to subroutines

C++ has full checking for subroutine parameters.
Do you have an example of what you think doesn't work?

> the referencing/dereferencing of things by address

C++ does not guarantee that dereferencing a null pointer
will be caught, although on many platforms this causes as
access violation which terminates the program.

Other than that, what does Ada do in regards to pointer
dereferencing that is safer than C++?

Re: Faulty languages and Liability

[Matthew Woodcraft]

In article <3D11F304.9030906@mail.com>, Hyman Rosen  <hyrosen@mail.com> wrote:
>Marin David Condic wrote:
> > Things like parameter passing to subroutines
>
>C++ has full checking for subroutine parameters.
>Do you have an example of what you think doesn't work?

'Slicing' of objects passed by value.


>> the referencing/dereferencing of things by address
>
>C++ does not guarantee that dereferencing a null pointer
>will be caught, although on many platforms this causes as
>access violation which terminates the program.
>
>Other than that, what does Ada do in regards to pointer
>dereferencing that is safer than C++?

Accessibility checks.

And pointers not explicitly initialised are null.

-M-

Re: Faulty languages and Liability

[Robert A Duff]

Matthew Woodcraft <mattheww@chiark.greenend.org.uk> writes:

> >Other than that, what does Ada do in regards to pointer
> >dereferencing that is safer than C++?
> 
> Accessibility checks.
> 
> And pointers not explicitly initialised are null.

Yes.  Also, you can't make a pointer to a stack variable (or component,
etc) without explicitly declaring it "aliased".

Oh, yeah, you can't "cast away const" in Ada.  At least not with a
normal type_conversion.

- Bob

Re: Faulty languages and Liability

[Hyman Rosen]

Robert A Duff wrote:
> Yes.  Also, you can't make a pointer to a stack variable (or component,
> etc) without explicitly declaring it "aliased".

That is only a notational device to inform the reader of the code.

> Oh, yeah, you can't "cast away const" in Ada.  At least not with a
> normal type_conversion.

C++ has const_cast<> for this, although an old C-style cast must
continue to work for backwards compatibility. And since C++ adopted
the mutable keyword, it's not even especially needed at all.

Notice that in both C and C++ it is illeall to cast away constness
from an actual const object. You may only do it to something which
is "accidentally" const because of parameter passing or references.

Re: Faulty languages and Liability

[Matthew Woodcraft]

In article <%rcR8.6726$cE5.5860@nwrddc02.gnilink.net>,
Hyman Rosen  <hyrosen@mail.com> wrote:
>Robert A Duff wrote:
>> Yes.  Also, you can't make a pointer to a stack variable (or component,
>> etc) without explicitly declaring it "aliased".
>
>That is only a notational device to inform the reader of the code.

Only in the same sense as any other compile-time check is. Are you
counting the compiler as a reader of the code?


>Notice that in both C and C++ it is illeall to cast away constness
>from an actual const object. You may only do it to something which
>is "accidentally" const because of parameter passing or references.

Illegal as in 'the compiler will complain if you do it', or illegal as
in 'random breakage at runtime'?

-M-

Re: Faulty languages and Liability

[Hyman Rosen]

Matthew Woodcraft wrote:
> Only in the same sense as any other compile-time check is. Are you
> counting the compiler as a reader of the code?

You're not telling the compiler anything special, since it knows
you want the object to be aliased when you take a pointer to it.
The reason to declare an object aliased is to inform the human
reader of the code that the object will be accessed through a
pointer.

> Illegal as in 'the compiler will complain if you do it', or illegal as
> in 'random breakage at runtime'?

You're kidding, right? We're talking about C and C++ here.
Random breakage at runtime, of course :-) Actually, the compiler
can't complain, because it doesn't know. I assume a compiler
could complain about obvious cases, but the ones where you change
the constness through a pointer or reference can't be detected
in all cases.

Re: Faulty languages and Liability

[Matthew Woodcraft]

In article <wqhR8.7310$cE5.5201@nwrddc02.gnilink.net>,
Hyman Rosen  <hyrosen@mail.com> wrote:
>Matthew Woodcraft wrote:
>> Only in the same sense as any other compile-time check is. Are you
>> counting the compiler as a reader of the code?
>
>You're not telling the compiler anything special, since it knows
>you want the object to be aliased when you take a pointer to it.

The interesting case is when I didn't want the object to be aliased,
but I tried to take a pointer to it.

In your sense, 'constant' doesn't tell the compiler anything special,
as it can see which objects are assigned to. But the associated
compile-time checks are still useful.

-M-

Re: Faulty languages and Liability

[Hyman Rosen]

Matthew Woodcraft wrote:
> In your sense, 'constant' doesn't tell the compiler anything special,
> as it can see which objects are assigned to. But the associated
> compile-time checks are still useful.

In C++ there's rather more to it than that. Temporaries passed by
reference can only go to parameters declared as const reference.
Furthermore, class methods can be overloaded by whether the object
is const.

Re: Faulty languages and Liability

[Pat Rogers]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:%rcR8.6726$cE5.5860@nwrddc02.gnilink.net...
> Robert A Duff wrote:
> > Yes.  Also, you can't make a pointer to a stack variable (or component,
> > etc) without explicitly declaring it "aliased".
>
> That is only a notational device to inform the reader of the code.

No, that allows the compiler to prevent dangling references.

Re: Faulty languages and Liability

[Hyman Rosen]

Pat Rogers wrote:
> No, that allows the compiler to prevent dangling references.

How's that? That is, what is the difference between the compiler
noticing which objects you take the address of, or you telling
the compiler which objects you intend to take the address of?

Re: Faulty languages and Liability

[Pat Rogers]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:PNvR8.12669$cE5.8689@nwrddc02.gnilink.net...
> Pat Rogers wrote:
> > No, that allows the compiler to prevent dangling references.
>
> How's that? That is, what is the difference between the compiler
> noticing which objects you take the address of, or you telling
> the compiler which objects you intend to take the address of?

Yes, from that angle there is no difference. (Note, however, that there is
certainly a difference from taking the address of something, which the compiler
cannot help you with, and using the checked approach we're discussing via
'Access and aliased objects.  Taking the address of something for the purpose of
converting it to an access value is generally not recommended!)

However, marking objects as aliased does have an important effect that the
compiler cannot achieve by just noticing all the references (because the aliased
object will likely be compiled separately from the references).  Specifically,
it prevents the object from being stored in a way that precludes the later
access. For example, it prevents the object from being stored in a register.
See RM 13.1{24}.


--
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Faulty languages and Liability

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3D0E461A.8050207@mail.com>...
> Mike Silva wrote:
> > So then you're asserting that choice of language has absolutely no
> > effect on software quality?
> 
> Not no effect, but not enough of an effect to justify requiring
> under pain of lawsuit that one be used and that one not be used.

Nobody is suggesting that.  It is simply that (I repeat over and over)
using known flawed tools at some point becomes professional
negligence.  It is in most other endeavors.  Why do you resist this so
strongly?
> 
> > And you're also asserting that this is
> > the consensus opinion in the industry?
> 
> Nope. That's why so many places adopted Java. They just got
> tired of the risks of using Unchecked_Deallocation in their
> Ada code.

Ah yes, I remember all those discussions about replacing Ada with Java
well. :)
> 
> > Coincidentally, from the currently-being-discussed Hoare paper of 1980
> > (discussing such security checking as array bounds checking):
> > "In any respectible branch of engineering, failure to observe such
> > elementary precautions would have long been against the law."
> 
> I wonder why Ada compilers allow these checks to be turned off, then?

Because (a) it may not matter, or (b) it may be provable that the
checks are unneeded.  You understand that not all risks are equal, nor
all solutions identical, right?
> 
> > So, given the well-known falible nature of human programmers, if one
> > has the choice between well-known tools which perform many such checks
> > automatically, and tools which do not perform such checks
> > automatically, and if a falible programmer then uses tools of the
> > second type which contribute to a major software failure, has due
> > diligence been used?
> 
> Perhaps not in hiring that programmer. The tools in question are not
> equivalent in other aspects than safety, which is why the safe ones
> are not always chosen.

That's the cowboy approach to programming -- just don't write bad
programs!  The fact that it flies in the face of human nature, and
that programmers continue to write buggy code year after year, seems
never to sink in.  This attitude is often mentioned when our industry
is referred to as immature.

Mike

Re: Faulty languages and Liability

[newsfraser]

Hyman Rosen <hyrosen@mail.com> writes:

> I wonder why Ada compilers allow these checks to be turned off, then?

The run time checks are only part of the picture.  Many array bounds
violations simply can't happen, whether checks are on or not.
Get_Line can't write past the end of its string argument, for
example.  A loop over Array_Type'Range is always safe, and more
efficient than the equivalent C++ vector class because each access
doesn't need to be checked.

(btw, units are easy to do in Ada now :)

Fraser.

Re: Faulty languages and Liability

[Wes Groleau]

> > I wonder why Ada compilers allow these checks to be turned off, then?
> 
> The run time checks are only part of the picture.  Many array bounds

And a pragma to turn off checking on variable X
while within the scope of loop Y is a lot different
than a global option to turn off all checks.

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

Re: Faulty languages and Liability

[Steve O'Neill]

Hyman Rosen wrote:
> 
> Nope. That's why so many places adopted Java. They just got
> tired of the risks of using Unchecked_Deallocation in their
> Ada code.

Nice thought.  But I would bet lots of money that the primary reason
that
companies adopted Java was because that's what the rest of the herd was
doing.
Even more I would doubt that Unchecked_Anything was ever a
consideration.

The worker-bees saw it as the Next Great Thing and needed to have it on
their
resume to be viable next month. The manager-types were told that it was
better 
than sliced bread - it was cheaper, better, safer, etc., etc.  Some of
that
was likely true and some was just hype.  How you use the tool will
greatly
effect your mileage (as with any tool).

> > Coincidentally, from the currently-being-discussed Hoare paper of 1980
> > (discussing such security checking as array bounds checking):
> > "In any respectible branch of engineering, failure to observe such
> > elementary precautions would have long been against the law."
> 
> I wonder why Ada compilers allow these checks to be turned off, then?

Because 1) there was great fear that the performance penalties might be
too
great for some applications and 2) some folks believed that they could 
sufficiently test the software to the point that such checks were
unnecessary.
In my experience neither of these are valid (at least not since the
early 80's).

Re: Faulty languages and Liability

[Marin David Condic]

No, its still valid to need to turn off runtime checks in *some* areas and
applications. Imagine high-speed control loops in realtime apps or
incredibly large matrix calculations that you want to finish within our
lifetimes. I'll grant you that these situations are rare in comparison to
most apps ever developed, but they do exist. If reliability is needed and
speed is an issue, the typical answer is to either analyze or extensively
test before operating without the safety net.

I agree that *most* programs should not have the checks disabled. They don't
present enough overhead to significantly impact anything & you are better
off running with them.

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


"Steve O'Neill" <oneils@gbr.msd.ray.com> wrote in message
news:3D0F2C6D.14B0380E@gbr.msd.ray.com...
>
> Because 1) there was great fear that the performance penalties might be
> too
> great for some applications and 2) some folks believed that they could
> sufficiently test the software to the point that such checks were
> unnecessary.
> In my experience neither of these are valid (at least not since the
> early 80's).

Re: Faulty languages and Liability

[AG]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0C7C0B.5000707@mail.com...
> Robert C. Leif wrote:
> > I was hoping to find a lawyer to speak on software product liability


> I also point out to you that when your house is broken into or your
> car is stolen, you're not going to have any luck suing the makers
> of the locks.


Well, not quite. That depends on what claims were made about the locks.
 I'm using a rather cheap, run-of-the-mill, car lock whose manufacturer
specifically guaranteed that, if a car is stolen while the lock was on, they
would refund insurance excess up to $1000. The warranty is valid for
3 years after the purchase (hmmm, note to self - need to check when
I got it ;) This seems like a rather clear-cut case of contractual
obligation,
doesn't it?

Re: Faulty languages and Liability

[Robert A Duff]

"AG" <a_n_g@x_t_r_a.c_o.n_z> writes:

> Well, not quite. That depends on what claims were made about the locks.

Software vendors typically make *no* claims about the proper operation
of their product, other than that they will replace physically defective
media.

The question is whether you can win a lawsuit anyway.

- Bob

Re: Faulty languages and Liability

[Ted Dennison]

David Botton wrote:
> I have been saying for year the day would come that software authors would
> start to be found liable for their bugs... the time is approaching....
...

Great. If you thought people hated Ada because the DoD forced them to 
use it, just wait until lawyers start forcing them to use it. ;-(

Re: Faulty languages and Liability

[Marin David Condic]

Lawyers will go after anyone for anything so long as there looks like there
might be a probable payday in it for them. :-) If someone put the bug in
some lawyer's ear that certain software errors could readily be eliminated
with a language change & that Any *Competent* Programmer(tm)  ought to know
that, I'm sure suit will be brought against someone.

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


"David Botton" <David@Botton.com> wrote in message
news:ugnt00ppv51s23@corp.supernews.com...
>
> Using Ada is the first step to solving these problems! Now we need to get
> some spokes people to help these lawyers go after faulty software
> manufactures for using faulty languages too :-)
>

Re: Faulty languages and Liability

[chris.danx]

"David Botton" <David@Botton.com> wrote in message
news:ugnt00ppv51s23@corp.supernews.com...
> I have been saying for year the day would come that software authors would
> start to be found liable for their bugs... the time is approaching....


I have no problem with tighting up software development legislation, but
governments and courts tend to screw things up.  If they create legislation
saying "you must build bug free software", then we all might as well go home
and start looking for a job in the local supermarket.  After all how many
programs are 100% bug free?

If they say "the software must do what it says on the tin and do so reliably
atleast 95% of the time, and you must avoid bugs as much as possible", then
great.  It means that software must do what it's suppost to, it must be
reliable and robust and relatively bug free.  That's what most of us here
strive to provide anyway, right?

A balance between reliability and reality is what's called for, but who
honostly thinks that's what we'll get?


Chris

Re: Faulty languages and Liability

[tmoran]

>A balance between reliability and reality is what's called for, but who
>honostly thinks that's what we'll get?
 Perhaps not your own preferred point on the balance, but a balance for
sure.  Consider cars, chain saws, hamburger, OTC painkillers, etc.
Even software has *some* kind of balance (MS sending their programmers
to a month long course on security must have been a non-trivial expense).
It just that most people think the balance needs to move quite a bit
more in the "reliability" direction.

Re: Faulty languages and Liability

[Mike Silva]

"David Botton" <David@Botton.com> wrote in message news:<ugnt00ppv51s23@corp.supernews.com>...
> I have been saying for year the day would come that software authors would
> start to be found liable for their bugs... the time is approaching....
> 
> http://story.news.yahoo.com/news?tmpl=story&u=/nm/20020615/tc_nm/bizliabilit
> y_software_dc_1
> 
> <<
> Researchers on both sides of the Atlantic say most reported security
> incidents are due to software defects that could easily be fixed.
> >>
> 
> Using Ada is the first step to solving these problems! Now we need to get
> some spokes people to help these lawyers go after faulty software
> manufactures for using faulty languages too :-)
> 
> David Botton

FWIW, I just read in comp.risks (Digest 22.11) that it is estimated
that software faults cost the U.S. about $60 billion per year.  They
actually refer to "inadequate software testing infrastructure" as the
problem, but I think they're confusing the real problem (incorrect
software) with one component of the solution (software testing). 
Anyway, $60 billion is getting up to what they in government circles
call "real money".

Mike