Have you ever had a bug caused by...

Have you ever had a bug caused by...

[Mike Silva]

While discussing (er, pushing) Ada with some C-coding co-workers today
I asked a question to which I knew the answer (always the best kind!):
 "Have you ever had a bug caused by accessing off the end of an
array?"  Well, of course, they all had to say yes.  Then I started
thinking of other bugs that they would have to admit to, and which
wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
but I thought it would be fun and useful to develop a group list as an
Ada advocacy tool.  For example:


Have you ever had a bug caused by accessing off the end of an array?

Have you ever had a bug caused by an implicit type conversion?

Have you ever had a bug caused by a variable getting set to a value
outside its designed range?

Have you ever had a bug caused by different type sizes on different
platforms?

Have you ever had a bug caused by mixing incompatible types?

Have you ever had a bug caused by passing parameters of incorrect
types?

Have you ever had a bug caused by passing parameters in an incorrect
order?

Have you ever had a bug caused by different data structure ordering on
different platforms?


And so on.  It might also be nice to have a section of "Have you ever
wished you could..." questions.

Anyway, such a list strikes me as a potentially useful piece of
advocacy, should anybody want to offer contributions.

Mike

Re: Have you ever had a bug caused by...

[Larry Kilgallen]

In article <27085883.0110191714.784d3d25@posting.google.com>, mjsilva697@earthlink.net (Mike Silva) writes:
> While discussing (er, pushing) Ada with some C-coding co-workers today
> I asked a question to which I knew the answer (always the best kind!):
>  "Have you ever had a bug caused by accessing off the end of an
> array?"  Well, of course, they all had to say yes.  Then I started
> thinking of other bugs that they would have to admit to, and which
> wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> but I thought it would be fun and useful to develop a group list as an
> Ada advocacy tool.  For example:
> 
> 
> Have you ever had a bug caused by accessing off the end of an array?
> 
> Have you ever had a bug caused by an implicit type conversion?
> 
> Have you ever had a bug caused by a variable getting set to a value
> outside its designed range?
> 
> Have you ever had a bug caused by different type sizes on different
> platforms?
> 
> Have you ever had a bug caused by mixing incompatible types?
> 
> Have you ever had a bug caused by passing parameters of incorrect
> types?
> 
> Have you ever had a bug caused by passing parameters in an incorrect
> order?
> 
> Have you ever had a bug caused by different data structure ordering on
> different platforms?
> 
> 
> And so on.  It might also be nice to have a section of "Have you ever
> wished you could..." questions.
> 
> Anyway, such a list strikes me as a potentially useful piece of
> advocacy, should anybody want to offer contributions.
> 
> Mike

Have you ever had a bug caused by changing the list of parameters
to a subroutine in many places, but missing one ?

Re: Have you ever had a bug caused by...

[James Rogers]

Larry Kilgallen wrote:
> 
> In article <27085883.0110191714.784d3d25@posting.google.com>, mjsilva697@earthlink.net (Mike Silva) writes:
> > While discussing (er, pushing) Ada with some C-coding co-workers today
> > I asked a question to which I knew the answer (always the best kind!):
> >  "Have you ever had a bug caused by accessing off the end of an
> > array?"  Well, of course, they all had to say yes.  Then I started
> > thinking of other bugs that they would have to admit to, and which
> > wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> > but I thought it would be fun and useful to develop a group list as an
> > Ada advocacy tool.  For example:
> >
> >
> > Have you ever had a bug caused by accessing off the end of an array?
> >
> > Have you ever had a bug caused by an implicit type conversion?
> >
> > Have you ever had a bug caused by a variable getting set to a value
> > outside its designed range?
> >
> > Have you ever had a bug caused by different type sizes on different
> > platforms?
> >
> > Have you ever had a bug caused by mixing incompatible types?
> >
> > Have you ever had a bug caused by passing parameters of incorrect
> > types?
> >
> > Have you ever had a bug caused by passing parameters in an incorrect
> > order?
> >
> > Have you ever had a bug caused by different data structure ordering on
> > different platforms?
> >
> >
> > And so on.  It might also be nice to have a section of "Have you ever
> > wished you could..." questions.
> >
> > Anyway, such a list strikes me as a potentially useful piece of
> > advocacy, should anybody want to offer contributions.
> >
> > Mike
> 
> Have you ever had a bug caused by changing the list of parameters
> to a subroutine in many places, but missing one ?

Some more for the first section:

Have you ever had a bug caused by dereferencing a null pointer?

Have you ever had a bug caused by including a file more than once?

Have you ever had a bug caused by creating an object of an
incomplete forward declared type?

Have you ever had a bug caused by confusing two identifiers that
differed only in their case (i.e. count and Count)?

Have you ever had a bug caused by linking a file with identifiers
duplicating those in another file?

Have you ever had a bug caused by omitting a "break" in a
switch statement?



For the second section (for C and C++ users)

Have you ever wished you could specify several default function
parameter values and choose to override only one?

Have you ever wished you could call a function and pass
parameters in any order?

Have you ever wished you could define an array and be assured that
index bounds would be enforced?

Have you ever wished you could program threads for any system
without changing your code?

Have you ever wished you could efficiently define your own numeric
types?

Have you ever wished you could read and understand your own code
more than six months after creating it?

Have you ever wished you could define true multi-dimensional
arrays without overloading operators?

Have you ever wished you could define an array index beginning
at some value not 0 without wasting array space?

Have you ever wished you could print enumeration labels without
creating an array of strings or executing a switch statement?

Have you ever wished you could define two different enumerated
types in the same program where both types share some
enumeration labels?

Have you ever wished you could print numbers in binary without
creating your own function?

Have you ever wished you could compile your program to target the
Java Virtual Machine?

Have you ever wished you could execute virtual functions without
the use of a pointer or reference?

Have you ever wished you could distinguish between two virtual
functions based on their return type?


Jim Rogers
Colorado Springs, Colorado USA

Re: Have you ever had a bug caused by...

[Robert*]

For me, the most impressive thing about Ada development environemnt is this:

It is so hard to build an inconsistant program.

In the world of C/C++ and even Java, this problem is so common. Makefiles
are used to try to prevent this, but for anything more complex than a 
simple project, very few programmers know enough about Makefiles to
get all the dependencies done right.  gnatmake does all this work for
you.

In Java, there is also a problem there. You could develop a program 
with class A. But at run time, an older, or newer class A could be loaded
and used if it happened to be on different classpath, or a duplicate
such class exist at run time in another jar file, and few more such
conditions.

In C/C++, one could modify a header file, but not compile one source file
that depends on it, ending up with a program that is not build correctly.

So, for me, this one of the strongest points of Ada, if not the strongest 
point. Interesting that not much weight is given to this advantage of Ada
over many other development environments.

(btw, I have discovered in the official Sun packages, a number of 
duplicated java classes in different places, and those classes are out
of date from each others, ie. same class name, but different bytecode,
so depending on the classpath ordering, one could use a different 
class 'version' that what they expect.)

Re: Have you ever had a bug caused by...

[Bertrand Augereau]

> In the world of C/C++ and even Java, this problem is so common. Makefiles
> are used to try to prevent this, but for anything more complex than a
> simple project, very few programmers know enough about Makefiles to
> get all the dependencies done right.  gnatmake does all this work for
> you.

I think gnatmake is compiler specific, so you can say that running the gnu
preprocessor with flag -M would generate a Makefile for a set of C or C++
sources, which is almost equivalent.

Re: Have you ever had a bug caused by...

[Matthew Woodcraft]

"Bertrand Augereau" <tramboi@hotmail.com> writes:

> I think gnatmake is compiler specific, so you can say that running the gnu
> preprocessor with flag -M would generate a Makefile for a set of C or C++
> sources, which is almost equivalent.

gnatmake is compiler specific, but the requirement to refuse to build
an executable from inconsistent parts is part of the language.

-M-

Re: Have you ever had a bug caused by...

[Robert*]

In article <87k7xqa6qz.fsf@chiark.greenend.org.uk>, Matthew says...
>
>"Bertrand Augereau" <tramboi@hotmail.com> writes:
>
>> I think gnatmake is compiler specific, so you can say that running the gnu
>> preprocessor with flag -M would generate a Makefile for a set of C or C++
>> sources, which is almost equivalent.
>
>gnatmake is compiler specific, but the requirement to refuse to build
>an executable from inconsistent parts is part of the language.
>
 
thank you, that is what I was about to say. 

Re: Have you ever had a bug caused by...

[Bertrand Augereau]

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

Agreed.

"Matthew Woodcraft" <mattheww@chiark.greenend.org.uk> a �crit dans le
message news: 87k7xqa6qz.fsf@chiark.greenend.org.uk...
> "Bertrand Augereau" <tramboi@hotmail.com> writes:
>
> > I think gnatmake is compiler specific, so you can say that running the
gnu
> > preprocessor with flag -M would generate a Makefile for a set of C or
C++
> > sources, which is almost equivalent.
>
> gnatmake is compiler specific, but the requirement to refuse to build
> an executable from inconsistent parts is part of the language.
>
> -M-

Re: Have you ever had a bug caused by...

[Robert Dewar]

"Bertrand Augereau" <tramboi@hotmail.com> wrote in message news:<9qrmjb$pft$1@wanadoo.fr>...
> > In the world of C/C++ and even Java, this problem is so common. Makefiles
> > are used to try to prevent this, but for anything more complex than a
> > simple project, very few programmers know enough about Makefiles to
> > get all the dependencies done right.  gnatmake does all this work for
> > you.
> 
> I think gnatmake is compiler specific, so you can say that running the gnu
> preprocessor with flag -M would generate a Makefile for a set of C or C++
> sources, which is almost equivalent.


Sure, but it is easy to build an inconsistent program in
C or C++, makefile checking is insufficient, it tells you
when you need to compile a new source file, but if you go
back to an older version of a source file, you won't be
told, and for example you can have a program where some
units are built with one version of a header, and some 
with another. That can't happen in Ada.

Re: Have you ever had a bug caused by...

[Ted Dennison]

In article <3BD0DD8D.E05F85BC@worldnet.att.net>, James Rogers says...
>
>Have you ever had a bug caused by including a file more than once?

..or including a series of files in the wrong order. That matters
sometimes.(yuk!)

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Have you ever had a bug caused by...

[Dr Adrian Wrigley]

Mike Silva wrote:
> Have you ever had a bug caused by accessing off the end of an array?
>...
> Have you ever had a bug caused by a variable getting set to a value
> outside its designed range?

These are occasionally the *cause* of a bug.  But more often they
are the *effect* of a bug. (Maybe it's just semantics, but I
think of some items on the list as the result of bugs, not the cause)

In C, execution problems can arise due to a bug, and things collapse
much later, leading to much confusion and wasted time.

In Ada, execution usually fails much earlier because of range checking,
leading the programmer to focus on the relevant part of the code.
This proximity of cause and effect is a big help debugging Ada.
--
Dr Adrian Wrigley

Re: Have you ever had a bug caused by...

[Mike Silva]

Dr Adrian Wrigley <amtw@linuxchip.demon.co.uk> wrote in message news:<3BD1CA15.6492D999@linuxchip.demon.co.uk>...
> Mike Silva wrote:
> > Have you ever had a bug caused by accessing off the end of an array?
> >...
> > Have you ever had a bug caused by a variable getting set to a value
> > outside its designed range?
> 
> These are occasionally the *cause* of a bug.  But more often they
> are the *effect* of a bug. (Maybe it's just semantics, but I
> think of some items on the list as the result of bugs, not the cause)
> 
> In C, execution problems can arise due to a bug, and things collapse
> much later, leading to much confusion and wasted time.
> 
> In Ada, execution usually fails much earlier because of range checking,
> leading the programmer to focus on the relevant part of the code.
> This proximity of cause and effect is a big help debugging Ada.

I agree that some of the list items are the result, not the cause, of
a bug; but as you say, Ada will help by screaming bloody murder much
more quickly.  I was taking some liberties with the language -- maybe
somebody can think of a more accurate but still snappy formulation.

Mike

Re: Have you ever had a bug caused by...

[Larry Kilgallen]

In article <27085883.0110201709.4b4047b2@posting.google.com>, mjsilva697@earthlink.net (Mike Silva) writes:

> I agree that some of the list items are the result, not the cause, of
> a bug; but as you say, Ada will help by screaming bloody murder much
> more quickly.  I was taking some liberties with the language -- maybe
> somebody can think of a more accurate but still snappy formulation.

	Have you ever had a bug when...

	Have you ever had a bug where...

Those aren't exactly "more accurate" -- perhaps "more fuzzy" :-)

Re: Have you ever had a bug caused by...

[Marin David Condic]

Perhaps you could collect up the contributions and submit it to AdaPower for
the FAQ:

Q: What sort of errors does Ada do an excellent job of catching that
typically go unnoticed in other languages?

A: <list of typical C/C++/Java bugs that can't happen in Ada>

I wish I still had the link to a study done by Lucent concerning C errors in
one of their big switches. The bulk of the most common errors were things
that couldn't happen in Ada. Their answer? Publish coding standards and
audit the code by hand. Let's see..... My fully burdened labor cost is how
many dollars an hour? And a compiler can do the checking at how many dollars
an hour? And if I field a product with errors in it, that could cost me how
many dollars in warranty costs and lawsuits? Hmmmmmmmm...... Why is it I'm
insisting on using C again??? :-)

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

"Mike Silva" <mjsilva697@earthlink.net> wrote in message
news:27085883.0110191714.784d3d25@posting.google.com...
> While discussing (er, pushing) Ada with some C-coding co-workers today
> I asked a question to which I knew the answer (always the best kind!):
>  "Have you ever had a bug caused by accessing off the end of an
> array?"  Well, of course, they all had to say yes.  Then I started
> thinking of other bugs that they would have to admit to, and which
> wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> but I thought it would be fun and useful to develop a group list as an
> Ada advocacy tool.  For example:
>
>
> Have you ever had a bug caused by accessing off the end of an array?
>
> Have you ever had a bug caused by an implicit type conversion?
>
> Have you ever had a bug caused by a variable getting set to a value
> outside its designed range?
>
> Have you ever had a bug caused by different type sizes on different
> platforms?
>
> Have you ever had a bug caused by mixing incompatible types?
>
> Have you ever had a bug caused by passing parameters of incorrect
> types?
>
> Have you ever had a bug caused by passing parameters in an incorrect
> order?
>
> Have you ever had a bug caused by different data structure ordering on
> different platforms?
>
>
> And so on.  It might also be nice to have a section of "Have you ever
> wished you could..." questions.
>
> Anyway, such a list strikes me as a potentially useful piece of
> advocacy, should anybody want to offer contributions.
>
> Mike

Re: Have you ever had a bug caused by...

[Martin Dowie]

> I wish I still had the link to a study done by Lucent concerning C errors
in
> one of their big switches. The bulk of the most common errors were things
> that couldn't happen in Ada. Their answer? Publish coding standards and
> audit the code by hand. Let's see..... My fully burdened labor cost is how
> many dollars an hour? And a compiler can do the checking at how many
dollars
> an hour? And if I field a product with errors in it, that could cost me
how
> many dollars in warranty costs and lawsuits? Hmmmmmmmm...... Why is it I'm
> insisting on using C again??? :-)

I have access to that report - do you wish it e-mailed to you? (~290k pdf
file)

Re: Have you ever had a bug caused by...

[Marin David Condic]

That would be nice. See my e-mail address in the .SIG. Thanks.

It seems like that report would be a handy one to cite in some sort of
advocacy setting. Don't know what the right forum would be or what the
copyright problems might be. Perhaps it could be something that is distilled
into a Q/A for the FAQ. Or maybe a short paper that explains the benefits of
Ada vs C, et alia, and cites that (and maybe other) studies.

Any ideas as to how to make it available in some manner to support 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
Web:      http://www.mcondic.com/


"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message
news:3bd44e29$1@pull.gecm.com...
> > I wish I still had the link to a study done by Lucent concerning C
errors
> in
> > one of their big switches. The bulk of the most common errors were
things
> > that couldn't happen in Ada. Their answer? Publish coding standards and
> > audit the code by hand. Let's see..... My fully burdened labor cost is
how
> > many dollars an hour? And a compiler can do the checking at how many
> dollars
> > an hour? And if I field a product with errors in it, that could cost me
> how
> > many dollars in warranty costs and lawsuits? Hmmmmmmmm...... Why is it
I'm
> > insisting on using C again??? :-)
>
> I have access to that report - do you wish it e-mailed to you? (~290k pdf
> file)
>
>

Re: Have you ever had a bug caused by...

[Mike Silva]

http://www.lucent.com/minds/techjournal/apr-jun1998/pdf/paper01.pdf

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9r1bkl$4po$1@nh.pace.co.uk>...
> 
> I wish I still had the link to a study done by Lucent concerning C errors in
> one of their big switches. The bulk of the most common errors were things
> that couldn't happen in Ada. Their answer? Publish coding standards and
> audit the code by hand. Let's see..... My fully burdened labor cost is how
> many dollars an hour? And a compiler can do the checking at how many dollars
> an hour? And if I field a product with errors in it, that could cost me how
> many dollars in warranty costs and lawsuits? Hmmmmmmmm...... Why is it I'm
> insisting on using C again??? :-)
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> "Mike Silva" <mjsilva697@earthlink.net> wrote in message
> news:27085883.0110191714.784d3d25@posting.google.com...
> > While discussing (er, pushing) Ada with some C-coding co-workers today
> > I asked a question to which I knew the answer (always the best kind!):
> >  "Have you ever had a bug caused by accessing off the end of an
> > array?"  Well, of course, they all had to say yes.  Then I started
> > thinking of other bugs that they would have to admit to, and which
> > wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> > but I thought it would be fun and useful to develop a group list as an
> > Ada advocacy tool.  For example:
> >
> >
> > Have you ever had a bug caused by accessing off the end of an array?
> >
> > Have you ever had a bug caused by an implicit type conversion?
> >
> > Have you ever had a bug caused by a variable getting set to a value
> > outside its designed range?
> >
> > Have you ever had a bug caused by different type sizes on different
> > platforms?
> >
> > Have you ever had a bug caused by mixing incompatible types?
> >
> > Have you ever had a bug caused by passing parameters of incorrect
> > types?
> >
> > Have you ever had a bug caused by passing parameters in an incorrect
> > order?
> >
> > Have you ever had a bug caused by different data structure ordering on
> > different platforms?
> >
> >
> > And so on.  It might also be nice to have a section of "Have you ever
> > wished you could..." questions.
> >
> > Anyway, such a list strikes me as a potentially useful piece of
> > advocacy, should anybody want to offer contributions.
> >
> > Mike

Re: Have you ever had a bug caused by...

[David Bolen]

mjsilva697@earthlink.net (Mike Silva) writes:

> While discussing (er, pushing) Ada with some C-coding co-workers today
> I asked a question to which I knew the answer (always the best kind!):
>  "Have you ever had a bug caused by accessing off the end of an
> array?"  Well, of course, they all had to say yes.  Then I started
> thinking of other bugs that they would have to admit to, and which
> wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> but I thought it would be fun and useful to develop a group list as an
> Ada advocacy tool.  For example:

I'm curious as to how Ada _prevents_ such bugs.  Are you saying that
no Ada programmer has ever had a bug caused by walking off the end of
an array either?

I'll buy that Ada will catch that error more quickly than in C, and
probably help isolate the problem more quickly.  And even that by
using attributes such as Range, Low and High that you can write more
robust code to avoid the issue (which is no small benefit).  But given
that you can still compute indices and then attempt to dereference
based on those computations, there has to be the occasional bug that
is introduced through the use of indices that overflow the array.

And that's different from saying "wouldn't occur in Ada" ... there's a
difference between better handling of the bug, and not having the bug
ever occur.  Or to put it another way, if I have a bug that creates
this condition (or say, tries to set a value outside its range, as in
another example), generating an exception - even if handled - still
implies the bug exists.

Some of the suggested items appear to be language checks that are
completely possible at compile time, for which I'd buy the "can't
happen" argument.  But any issues that can occur at runtime and
require runtime checks and exceptions don't, IMHO, prevent bugs, but
simply act to make it easier to diagnose and manage them when they do
occur.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Have you ever had a bug caused by...

[Marin David Condic]

The point is fair, but usually what gets considered a "Bug" is something
that makes it out of development and is discovered during some kind of
formal test or into a fielded system. The developer going through the
edit-compile-link-run development cycle and generating an error in the
process doesn't really count as a "defect" in the end product.

I understand what you are saying: Ada programmers can still make the same
mistakes in coding that C programmers can make. But the point is that those
errors may not get past the compiler and/or the initial execution fo the
code.

There is also an advantage to getting some kind of runtime exception in a
fielded system as well. If an index gets out of range under unusual
conditions not tested for, yes this is a programmer error. But unlike
silently running off the end of an array and scrogging memory with possibly
non-fatal, yet serious problems being generated, Ada is going to halt the
code and (if the implementation is nice!) report where it stopped and why.
In most apps that is *usually* a good thing.

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


"David Bolen" <db3l@fitlinxx.com> wrote in message
news:usncbuz01.fsf@ctwd0143.fitlinxx.com...
> mjsilva697@earthlink.net (Mike Silva) writes:
>
> > While discussing (er, pushing) Ada with some C-coding co-workers today
> > I asked a question to which I knew the answer (always the best kind!):
> >  "Have you ever had a bug caused by accessing off the end of an
> > array?"  Well, of course, they all had to say yes.  Then I started
> > thinking of other bugs that they would have to admit to, and which
> > wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> > but I thought it would be fun and useful to develop a group list as an
> > Ada advocacy tool.  For example:
>
> I'm curious as to how Ada _prevents_ such bugs.  Are you saying that
> no Ada programmer has ever had a bug caused by walking off the end of
> an array either?
>
> I'll buy that Ada will catch that error more quickly than in C, and
> probably help isolate the problem more quickly.  And even that by
> using attributes such as Range, Low and High that you can write more
> robust code to avoid the issue (which is no small benefit).  But given
> that you can still compute indices and then attempt to dereference
> based on those computations, there has to be the occasional bug that
> is introduced through the use of indices that overflow the array.
>
> And that's different from saying "wouldn't occur in Ada" ... there's a
> difference between better handling of the bug, and not having the bug
> ever occur.  Or to put it another way, if I have a bug that creates
> this condition (or say, tries to set a value outside its range, as in
> another example), generating an exception - even if handled - still
> implies the bug exists.
>
> Some of the suggested items appear to be language checks that are
> completely possible at compile time, for which I'd buy the "can't
> happen" argument.  But any issues that can occur at runtime and
> require runtime checks and exceptions don't, IMHO, prevent bugs, but
> simply act to make it easier to diagnose and manage them when they do
> occur.
>
> --
> -- David
> --
> /-----------------------------------------------------------------------\
>  \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
>   |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
>  /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
> \-----------------------------------------------------------------------/

Re: Have you ever had a bug caused by...

[Robert*]

In article <9r25o0$fla$1@nh.pace.co.uk>, "Marin says...
 
> If an index gets out of range under unusual
>conditions not tested for, yes this is a programmer error. But unlike
>silently running off the end of an array and scrogging memory with possibly
>non-fatal, yet serious problems being generated, Ada is going to halt the
>code and (if the implementation is nice!) report where it stopped and why.
>In most apps that is *usually* a good thing.
>
 
When Java came out, everyone was so excited about it, and how much more
reliable it was, more than C, and the most common thing sited was that
it detected array overrun conditions are run-time, wow! as if this was a
new concept, and Ada had that for 15 years before Java was born.

Yes, Ada does even more today than Java/C/C++. None of those other languages
for example will detect a floating point overflow/underflow at run-time, but
Ada will. 

Re: Have you ever had a bug caused by...

[Marin David Condic]

It isn't even new with Ada. Pascal was doing this long before Ada was
invented. IIRC, some Fortran compilers would generate runtime exceptions on
an array index out of bounds. It was one of those things left out of C
because C was supposed to be a high-level assembly language. "You want
checks? Put them in yourself!"

Most of the kinds of checking that Ada does are not particularly new.
Language designers have been putting in compile & runtime checks on all
kinds of things for years. Its really just a difference in mentality. The C
mindset being "Don't burden the code with anything that doesn't need to be
there so we get maximum possible efficiency". Maybe at one time that made
some sense, but with the speed of today's processors and in most application
arenas it really doesn't make much sense. The small percentage of CPU used
for runtime checks just doesn't show up above the noise level. (Of course
there are still some apps for which it *does* make sense, and that's why Ada
lets you disable the checks as you need to.)

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


"Robert*@" <Robert_member@newsguy.com> wrote in message
news:9r2f090nu2@drn.newsguy.com...
>
> When Java came out, everyone was so excited about it, and how much more
> reliable it was, more than C, and the most common thing sited was that
> it detected array overrun conditions are run-time, wow! as if this was a
> new concept, and Ada had that for 15 years before Java was born.
>
> Yes, Ada does even more today than Java/C/C++. None of those other
languages
> for example will detect a floating point overflow/underflow at run-time,
but
> Ada will.
>

Re: Have you ever had a bug caused by...

[John English]

Marin David Condic wrote:
> ... Its really just a difference in mentality. The C
> mindset being "Don't burden the code with anything that doesn't need to be
> there so we get maximum possible efficiency".

Odd, considering how much easier it is for a compiler to optimise out
unnecessary range checks than for a human to try and identify safe
situations and leave out the checks... It's easier for a human to wrap
the variable access in a function which always range checks and which
the compiler can't optimise away, or to omit checking altogether.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Have you ever had a bug caused by...

[Marin David Condic]

Never said I was in favor of it - just observing that the C design
philosophy was to make an extremely simple compiler that didn't put in
anything you didn't specifically create. It is really a high level
assembler.

Designing in C, I find myself utilizing the Harley Davidson Design
Principle: "If it breaks, make it bigger. If it sticks out, chrome it!" :-)

I think that for easily 75% or more of the programs ever written in the
world today, a compiler could safely leave in all sorts of range checks and
other runtime safety features and nobody would ever notice they were there
from a performance standpoint. If a compiler can be smart enough to
eliminate some of the checks on its own - great! If the compiler will let me
turn them off when I might be in those 25% of the cases where it matters,
fine! Ada certainly makes all of that possible.

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


"John English" <je@brighton.ac.uk> wrote in message
news:3BD7DF3B.1E5F435B@brighton.ac.uk...
>
> Odd, considering how much easier it is for a compiler to optimise out
> unnecessary range checks than for a human to try and identify safe
> situations and leave out the checks... It's easier for a human to wrap
> the variable access in a function which always range checks and which
> the compiler can't optimise away, or to omit checking altogether.
>

Re: Have you ever had a bug caused by...

[Ted Dennison]

In article <9r9aoh$6fm$1@nh.pace.co.uk>, Marin David Condic says...
>Designing in C, I find myself utilizing the Harley Davidson Design
>Principle: "If it breaks, make it bigger. If it sticks out, chrome it!" :-)

That seems to have been the general principle behind the design of C++ as well.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Have you ever had a bug caused by...

[Ted Dennison]

In article <3BD7DF3B.1E5F435B@brighton.ac.uk>, John English says...
>Odd, considering how much easier it is for a compiler to optimise out
>unnecessary range checks than for a human to try and identify safe
>situations and leave out the checks... It's easier for a human to wrap
>the variable access in a function which always range checks and which
>the compiler can't optimise away, or to omit checking altogether.

There's nothing really that odd about it. Back when C was designed it really
wasn't all that easy for compilers to do that (they didn't have much memory or
CPU to work with). It then was much easier for humans to do their part, as the
programs C was designed for weren't all that large.

The thing that is odd is that people still think C is a good language to use for
developing *today's* software.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Have you ever had a bug caused by...

[Simon Wright]

Robert*@ <Robert_member@newsguy.com> writes:

> Yes, Ada does even more today than Java/C/C++. None of those other
> languages for example will detect a floating point
> overflow/underflow at run-time, but Ada will.

On Linux, GNAT's Float'Machine_Overflows is false.

   with GNAT.IO;
   procedure Fred is
      Last : Float := Float'Last;
   begin
      GNAT.IO.Put_Line (Float'Machine_Overflows'Img);
      GNAT.IO.Put_Line (Last'Img);
      Last := Last * 2.0;
      GNAT.IO.Put_Line (Last'Img);
   end Fred;

outputs

   FALSE
    3.40282E+38
    +Inf*******

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                     Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1800

Re: Have you ever had a bug caused by...

[David Bolen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> There is also an advantage to getting some kind of runtime exception in a
> fielded system as well. If an index gets out of range under unusual
> conditions not tested for, yes this is a programmer error. But unlike
> silently running off the end of an array and scrogging memory with possibly
> non-fatal, yet serious problems being generated, Ada is going to halt the
> code and (if the implementation is nice!) report where it stopped and why.
> In most apps that is *usually* a good thing.

Oh agreed.  But in any of those cases where such a situation may only
be detectable at runtime (and I agree Ada does also have a number that
can be caught during compiletime), then I'd avoid saying that Ada
precludes code with such a bug, and rather state that Ada helps ensure
a more robust system with its runtime checks.  The bug is obviously
still there.  Maybe its nit-picking, but if the game is why Ada is
better than xxx, then I think in fairness it needs to be approached
the right way.  As it is, such handling is of no small benefit, so I'd
hate it to be overshadowed by someone on the xxx side picking a
slightly too grandiose claim apart :-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Have you ever had a bug caused by...

[Mike Silva]

David Bolen <db3l@fitlinxx.com> wrote in message news:<usncbuz01.fsf@ctwd0143.fitlinxx.com>...
> mjsilva697@earthlink.net (Mike Silva) writes:
> 
> > While discussing (er, pushing) Ada with some C-coding co-workers today
> > I asked a question to which I knew the answer (always the best kind!):
> >  "Have you ever had a bug caused by accessing off the end of an
> > array?"  Well, of course, they all had to say yes.  Then I started
> > thinking of other bugs that they would have to admit to, and which
> > wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> > but I thought it would be fun and useful to develop a group list as an
> > Ada advocacy tool.  For example:
> 
> I'm curious as to how Ada _prevents_ such bugs.  Are you saying that
> no Ada programmer has ever had a bug caused by walking off the end of
> an array either?
> 
> I'll buy that Ada will catch that error more quickly than in C, and
> probably help isolate the problem more quickly.  And even that by
> using attributes such as Range, Low and High that you can write more
> robust code to avoid the issue (which is no small benefit).  But given
> that you can still compute indices and then attempt to dereference
> based on those computations, there has to be the occasional bug that
> is introduced through the use of indices that overflow the array.
> 
> And that's different from saying "wouldn't occur in Ada" ... there's a
> difference between better handling of the bug, and not having the bug
> ever occur.  Or to put it another way, if I have a bug that creates
> this condition (or say, tries to set a value outside its range, as in
> another example), generating an exception - even if handled - still
> implies the bug exists.
> 
> Some of the suggested items appear to be language checks that are
> completely possible at compile time, for which I'd buy the "can't
> happen" argument.  But any issues that can occur at runtime and
> require runtime checks and exceptions don't, IMHO, prevent bugs, but
> simply act to make it easier to diagnose and manage them when they do
> occur.

You're right -- I was imprecise in my language, and Ada has enough
real advantages that it doesn't need hyperbole.  As you say, some
types of bugs are completely prevented, others should never happen
when using the proper idioms (such as the use of attributes), while
others are simply caught at a much earlier stage.  Each of these
outcomes is vastly preferable to one of those horrible "six degrees of
separation" bugs in C where it can take days or weeks to trace back
from discovered effect to root cause.

Mike

Re: Have you ever had a bug caused by...

[mike]

In article <27085883.0110222226.76e006a2@posting.google.com>,
mjsilva697@earthlink.net says...
> 

> Each of these
>outcomes is vastly preferable to one of those horrible "six degrees of
>separation" bugs in C where it can take days or weeks to trace back
>from discovered effect to root cause.
 
I love C.

companies pay me lots of $$ to maintain old C code full of bugs. I am
never out of work. All those long hrs I charge for looking for C bugs 
I could not do if the code was written in Ada, at least there will not be so
much time spend on chasing bugs years and years after the code was written.
 
thanks Dennis Ritchie and Brian Kernighan for comming up with C, I love 
you guys, you have invented the best job security language :)

Re: Have you ever had a bug caused by...

[Preben Randhol]

On 23 Oct 2001 02:40:51 -0700, mike @ nospam wrote:
>  
> I love C.
> 
> companies pay me lots of $$ to maintain old C code full of bugs. I am
> never out of work. All those long hrs I charge for looking for C bugs 
> I could not do if the code was written in Ada, at least there will not be so
> much time spend on chasing bugs years and years after the code was written.
>  
> thanks Dennis Ritchie and Brian Kernighan for comming up with C, I love 
> you guys, you have invented the best job security language :)

but if in stead of chasing bugs you could add new features which
would improve the bussiness of the companies that buy the product... :-)

Preben

Re: Have you ever had a bug caused by...

[Marin David Condic]

What always confounds me about it is that even when you can make a strong
business case for using Ada based on higher reliability, lower development
and maintenance cost, etc., and actually back it up with data, you still
lose because management will end up asking their techies about it (fair
enough) and the techies don't like Ada or don't want the headache of
switching to Ada, so they recommend against it. A manager can't be expected
to know all the technical aspects and they've got to trust their techies to
make those decisions, so I don't really blame them. That's why it is
important to make the case with the techies and get them to want to use Ada.

There are circumstances where the business case collapses. When the whole
surrounding development environment is in some other language, its hard to
make a case for using Ada. If the tools & resources are in C or C++ or Java,
you've got a lot of stuff to leverage by sticking with those languages. The
fact that you can bind to it with Ada doesn't really help because it is
expensive and time consuming to try to maintain more than one language for a
development job. If Ada had a large institutional backer and/or a full-up
environment for at least *some* development jobs, it would fare better.
(Note that Ada has had some pretty fair success in application arenas where
it has been able to compete feature for feature with other languages, such
as some embedded targets. That's the "All Other Things Being Equal..."
factor at work.)

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


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9tanr7.i1.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> but if in stead of chasing bugs you could add new features which
> would improve the bussiness of the companies that buy the product... :-)
>

Re: Have you ever had a bug caused by...

[Ted Dennison]

In article <9r3sen$dnj$1@nh.pace.co.uk>, Marin David Condic says...
>
>What always confounds me about it is that even when you can make a strong
>business case for using Ada based on higher reliability, lower development
>and maintenance cost, etc., and actually back it up with data, you still
>lose because management will end up asking their techies about it (fair
>enough) and the techies don't like Ada or don't want the headache of

Actually, I've seen more cases where the grunts like it, but management doesn't
for whatever reason (I quit trying to analyze their reasoning process when I
discovered it has little to do with reasoning).

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Have you ever had a bug caused by...

[Marin David Condic]

This is sometimes a problem as well. All too often some (pointy haired)
bosses have been busy reading industry journals and pick up on buzzwords and
think "this is the direction to go in" because everybody is writing about
it. Trade journals can suffer from the same GIGO phenomenon as computers:
Garbage In, Gospel Out.

We used to have an "insider" expression taken from a Dilbert commic: "Mauve
has more RAM..." to indicate when a manager was speaking techno-babel. It
had to do with Dilbert testing to see if the PHB knew what he was talking
about when he wanted to have Dilbert acquire a new relational database.
Dilbert asks what color it should be. The answer was mauve because "Mauve
has more RAM".

The sad thing about Dilbert is that Scott Adams is *not* making this stuff
up.

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


"Ted Dennison" <dennison@telepath.com> wrote in message
news:oggB7.39668$ev2.46706@www.newsranger.com...
>
> Actually, I've seen more cases where the grunts like it, but management
doesn't
> for whatever reason (I quit trying to analyze their reasoning process when
I
> discovered it has little to do with reasoning).
>

Re: Have you ever had a bug caused by...

[Harri J Haataja]

Marin David Condic wrote:
>
>The sad thing about Dilbert is that Scott Adams is *not* making this stuff
>up.

Indeed. So you better watch any little white dogs with glasses very
carefully.

-- 
Seagoon: Will my aeroplane need a hangar?
Crun:    It'd lose its shape hanging on a nail, you know.
	-- T.A.Milligan & L.Stephens 10 Jan 1957

Re: Have you ever had a bug caused by...

[Marc A. Criley]

Ted Dennison wrote:
> 
> In article <9r3sen$dnj$1@nh.pace.co.uk>, Marin David Condic says...
> >
> >What always confounds me about it is that even when you can make a strong
> >business case for using Ada based on higher reliability, lower development
> >and maintenance cost, etc., and actually back it up with data, you still
> >lose because management will end up asking their techies about it (fair
> >enough) and the techies don't like Ada or don't want the headache of
> 
> Actually, I've seen more cases where the grunts like it, but management doesn't
> for whatever reason (I quit trying to analyze their reasoning process when I
> discovered it has little to do with reasoning).

When mentioning Ada to some developers where I used to work that were
working on C++ projects, I found that a number of them had used Ada in
the past and liked it.  But then, when new projects started up with C++
as the implementation language, they, being good engineers, simply
learned the new language and went to work.

The _strident_ calls for C++ (and now Java) often seemed to come from a
small number of opinionated individuals who were only too happy to get
up in front of management or the customer and beat the pulpit on how "we
have to go where the market is going!".  The majority of these
individuals were on-staff types who hadn't coded in years...but
certainly knew how it ought to be done!

I had a a perpetual smouldering battle against one such faction on the
project on which I worked, who advocated tossing out a measurably
high-quality, efficient, reliable, maintainable weapon control simply
because it was written in Ada, and redo it in C++.

In a follow-on program, I knew that there was no chance of any new
subsystems being written in Ada, but these techno-surfers were
advocating writing a soft realtime mission- and safety-critical portion
of the system in Java--and not today's Java, but 1999 Java.  Even the
skeletal version done for the proposal demo was unstable and a total dog
on performance.  I went ballistic over that and the blind advocacy fell
appart, with the system ending up being proposed in C++.  (And I knew
the lead designer was a very competent engineer, so I had less heartburn
than I might've otherwise.)

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

Re: Have you ever had a bug caused by...

[Jeffrey Carter]

"Marc A. Criley" wrote:
> 
> When mentioning Ada to some developers where I used to work that were
> working on C++ projects, I found that a number of them had used Ada in
> the past and liked it.  But then, when new projects started up with C++
> as the implementation language, they, being good engineers, simply
> learned the new language and went to work.

When new projects started with substandard steel as the implementation
material, they, being good civil engineers, simply built the bridge with
it.

Of course, when the bridge collapses and kills people, the civil
engineers go to jail. When the S/W fails, the manager gets promoted.

-- 
Jeffrey Carter

Re: Have you ever had a bug caused by...

[Marin David Condic]

Well, if they were *good* engineers, they'd design to the strength of the
materials they had. It would be the construction contractor using a grade of
steel of lower quality than specified who would go to jail. :-)

The point is taken, but as an engineer, one has to often work with what is
available and not with what might be optimal.

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


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3BD70EA2.655805A6@boeing.com...
>
> When new projects started with substandard steel as the implementation
> material, they, being good civil engineers, simply built the bridge with
> it.
>
> Of course, when the bridge collapses and kills people, the civil
> engineers go to jail. When the S/W fails, the manager gets promoted.
>

(Off topic:) Quality

[Anders Wirzenius]

Marin David Condic wrote in message <9r754q$2r1$1@nh.pace.co.uk>...
>Well, if they were *good* engineers, they'd design to the strength of the
>materials they had. It would be the construction contractor using a grade
of
>steel of lower quality than specified who would go to jail. :-)

Reminds me of a picture I saw on the wall in the office of an offshore oil
platform design project:
"When the storm whines around your ears and you cling to the hand rail
on the deck, remember, that this rail was made by the supplier
who came with the lowest bid."

Anders Wirzenius

Re: Have you ever had a bug caused by...

[John English]

Mike Silva wrote:
> 
> While discussing (er, pushing) Ada with some C-coding co-workers today
> I asked a question to which I knew the answer (always the best kind!):
>  "Have you ever had a bug caused by accessing off the end of an
> array?"  Well, of course, they all had to say yes.  Then I started
> thinking of other bugs that they would have to admit to, and which
> wouldn't occur in Ada.  Nothing new here (Ada prevents many bugs...),
> but I thought it would be fun and useful to develop a group list as an
> Ada advocacy tool.  For example:
> 
> Have you ever had a bug caused by accessing off the end of an array?

What about:
Have you ever had a bug caused by a one-character typo? E.g.:
   if (a = 0) { ... }
or:
   while (x);
   { ... }

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Have you ever had a bug caused by...

[Wes Groleau]

John English wrote:
> Have you ever had a bug caused by a one-character typo? E.g.:

Since your examples were in C, I get a kick out of this one:

some_file.h, line 1537:

   define THE_MAX = 100

my_file.c, line whatever:

   for (i=THE_MAX; i--; i=0) {...}

   OR

   for (i=0; i++; i=THE_MAX)

   OR

   goal=THE_MAX; /* set a new goal */

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

Re: Have you ever had a bug OOPS

[Wes Groleau]

Someone pointed out that I goofed in my C syntax.
Here is the correction:

> some_file.h, line 1537:
> 
>    define THE_MAX = 100
> 
> my_file.c, line whatever:
> 
>    for (i=THE_MAX; i==0; i--) {...}
> 
>    OR
> 
>    for (i=0; i=THE_MAX; i++)
> 
>    OR
> 
>    goal=THE_MAX; /* set a new goal */

And just in case it's obscure, the point was
that after preprocessing, the error in the header file
means one loop never ends, the other is stopped immediately,
and goal is unchanged.  Of course, the second loop has an error
of its own or it would not compile.

Interesting, too, that one of the mistakes I made in my first
post is the reverse of the one I was trying to illustrate!

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

Re: Have you ever had a bug OOPS

[David Thompson]

Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote :
>
> Someone pointed out that I goofed in my C syntax.
> Here is the correction:
>
> > some_file.h, line 1537:
> >
> >    define THE_MAX = 100
> >
This still isn't valid.  You meant #define (optionally plus space).
And the bug is that you put an = between the identifier and
the intended value, which is correct for a regular variable
but not for the rather different preprocessor syntax.

> > my_file.c, line whatever:
...
> >    goal=THE_MAX; /* set a new goal */
>
> And just in case it's obscure, the point was
> that after preprocessing, the error in the header file
> means one loop never ends, the other is stopped immediately,
> and goal is unchanged.  Of course, the second loop has an error
> of its own or it would not compile.
>
Not in Standard C.  Some (not all) "K&R1" preprocessors
might join a source character to a macro expansion like that,
but the Standard prohibits it (except if you ask for it by using
the "paste" operator ## on tokens _within_ a macro body).

AIUI on some embedded systems you get really lame old
C implementations, which might still do this; but you might
get no Ada implementation at all, which is hardly better.

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