How Ada could have prevented the Red Code distributed denial of service attack.
raj
1. Buffer overflow
See:
.ida "Code Red" Worm
http://www.eeye.com/html/Research/Advisories/AL20010717.html
for a recent , readable account see:
Win32 Buffer Overflows (Location, Exploitation and Prevention)
dark spyrit AKA Barnaby Jack
http://www.phrack.org/show.php?p=55&a=15
2. Disseminated metastasis
see:
Distributed Metastasis:
A Computer Network Penetration Methodology
by Andrew J. Stewart
http://www.packetfactory.net/papers/Distributed_Metastatis/distributed_metastasis.doc
or Phrack 55
http://www.phrack.org/show.php?p=55&a=16
The buffer overflow occurs because of an old and well known bug in the
C libraries.
Using Ada or another modern language like Ocaml or Mozart could have
prevented this, thus stopping the worm before it infected the very
first IIS server.
Martin Ambuhl
[Ada advocacy rant]
Ada advocacy belongs in Ada groups. In comp.lang.c, comp.lang.c++, and
comp.lang.functional your crap is at best spam. Perhaps Ada will teach you
how to cease being a troll.
Daniel Fischer
- followup ("raj" <isra...@optushome.com.au>)
> Red Code uses a combination of:
>
> 1. Buffer overflow
>
> See:
> .ida "Code Red" Worm
~~~~
> http://www.eeye.com/html/Research/Advisories/AL20010717.html for a
> recent , readable account see:
>
> Win32 Buffer Overflows (Location, Exploitation and Prevention)
~~~~~
> dark spyrit AKA Barnaby Jack
> http://www.phrack.org/show.php?p=55&a=15
> The buffer overflow occurs because of an old and well known bug in the C
> libraries.
> Using Ada or another modern language like Ocaml or Mozart could have
> prevented this, thus stopping the worm before it infected the very first
> IIS server.
~~~
Get a clue. :)
Daniel
--
IMO, anyway.
end message by (Daniel Fischer <d...@gueldenland.de>)
` { } \ | [ ] ' ~ :) ;) :/ :( <-- insert as needed
clc FAQ: http://www.eskimo.com/~scs/C-faq/top.html
raj
<d...@gueldenland.de> wrote:
>> Win32 Buffer Overflows (Location, Exploitation and Prevention)
> ~~~~~
>> The buffer overflow occurs because of an old and well known bug in the C
>> libraries.
>> Using Ada or another modern language like Ocaml or Mozart could have
>> prevented this, thus stopping the worm before it infected the very first
>> IIS server.
> ~~~
>Get a clue. :)
IIS servers run on Win32 systems....
IR Thomas
---------------------------------------------------
VI VI XIII
Roman Neighbour of the Beast
Richard Bos
HaaaHahahahaha....
You really are a complete imbecile, aren't you?
Go back to building big boys' toys for the President of the USA, and
leave the real programming to the real programmers.
Oh, and *plonk*.
Richard
Bart v Ingen Schenau
raj wrote in message <97ffmt0ccpeqe2s34...@4ax.com>...
>On Wed, 01 Aug 2001 07:01:13 +0200, "Daniel Fischer"
><d...@gueldenland.de> wrote:
>
>
>>> Win32 Buffer Overflows (Location, Exploitation and Prevention)
>> ~~~~~
>>> The buffer overflow occurs because of an old and well known bug in the C
>>> libraries.
>>> Using Ada or another modern language like Ocaml or Mozart could have
>>> prevented this, thus stopping the worm before it infected the very first
>>> IIS server.
>> ~~~
>>Get a clue. :)
>
>IIS servers run on Win32 systems....
And your point is?
>
>IR Thomas
Bart v Ingen Schenau
Mike Smith
news:ppsemtojqkqsqpfvj...@4ax.com...
>
> The buffer overflow occurs because of an old and well known bug in the
> C libraries.
The buffer overflow occurs because of a bug in the *Microsoft* C library.
This is not endemic to C or C++ in general. And, what, no one has ever
found a bug in Ada?
--
Mike Smith
Preben Randhol
> The buffer overflow occurs because of a bug in the *Microsoft* C library.
> This is not endemic to C or C++ in general.
The point is that if you look at the security bugs in Linux or Microsoft
software they consists mainly of buffer overflow bugs. This comes from
using languages such as C and C++ which allow buffer overflow due to
their design. Other languages eliminate this problem to a large extent.
--
Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
"i too once thought that when proved wrong that i lost somehow"
- i was hoping, alanis morisette
Scott Ingram
I am not exactly sure what the point of "raj"'s post was,
but David Wheeler's "Secure Programming for Linux and Unix
HOWTO" (part of the Linux Documentation Project and also
available at http://www.dwheeler.com) covers this topic in
detail, as well as strategies for coping with it. And of
course you can write buggy code in Ada--what's the point
of such a powerful language if you can't make it do what you
want? Its just that you really have to want a buffer overflow
to make it happen :)
--
Scott Ingram
Vice-Chair, Baltimore SIGAda
System Development and Operational Support Group
Johns Hopkins University Applied Physics Laboratory
Robert Dewar
Sounds like Mike is not familiar with Ada. Of course Ada does not
guarantee freedom from bugs, but for many reasons it does tend to
eliminate obvious goofs like buffer overruns, which are indeed
"endemic" to C and C++ in that these languages do not provide any
help for avoiding such bugs, and as we know these buffer overrun
bugs have time and time again proved weak spots in code written
in C/C++.
Ted Dennison
says...
>
>"Mike Smith" <smi...@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpm...@corp.supernews.com>...
>> This is not endemic to C or C++ in general. And, what, no one has ever
>> found a bug in Ada?
>
>
>Sounds like Mike is not familiar with Ada. Of course Ada does not
>guarantee freedom from bugs, but for many reasons it does tend to
>eliminate obvious goofs like buffer overruns, which are indeed
>"endemic" to C and C++ in that these languages do not provide any
>help for avoiding such bugs, and as we know these buffer overrun
>bugs have time and time again proved weak spots in code written
>in C/C++.
Raj pretty much had the right of it. Exploitable buffer overflows are a known
*class* of bugs that are pretty much endemic with C (and C++ that uses C) code.
On the other hand, you actually have to go fairly far out of your way to get an
exploitable buffer overflow out of Ada code. You'd have to disable array range
checks (and possibly constraint checks too) with either a pragma or a compiler
flag when the sources are built. It can be done when you need to (sometimes the
extra speed is important), but most folks use the default, which is immune.
If you don't think this is a big problem, check out this cracker website, which
is dedicated to teaching young script kiddies how to exploit Windows Buffer
Overflows: http://www.cultdeadcow.com/cDc_files/cDc-351/
My own company blocks it, but I understand it is titled: "The Tao of Windows
Buffer Overflow". :-)
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
home email - mailto:denn...@telepath.com
Ted Dennison
>
>>"Mike Smith" <smi...@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpm...@corp.supernews.com>...
>>> The buffer overflow occurs because of a bug in the *Microsoft* C library.
>>> This is not endemic to C or C++ in general. And, what, no one has ever
>If you don't think this is a big problem, check out this cracker website, which
>is dedicated to teaching young script kiddies how to exploit Windows Buffer
>Overflows: http://www.cultdeadcow.com/cDc_files/cDc-351/
>My own company blocks it, but I understand it is titled: "The Tao of Windows
>Buffer Overflow". :-)
I found a mirror which folks like me behind facist firewalls may have an easier
time accessing. http://www.supportamerica.com/win_buff/win_buff_overflow.html .
If you don't understand the buffer overflow problem (which apparently, at least
Mike doesn't), its a highly reccomended read. They even come out and say that
there are languages that don't have this problem, but Microsoft was too lazy to
use one of them (a rough paraphrase of their words).
Lawrence Foard
Daniel Fischer <d...@gueldenland.de> wrote:
>> The buffer overflow occurs because of an old and well known bug in the C
>> libraries.
What does this have to do with C++? Any decent C++ programmer is using
std::string instead of char *.
>> Using Ada or another modern language like Ocaml or Mozart could have
>> prevented this, thus stopping the worm before it infected the very first
>> IIS server.
> ~~~
Or use of the features of a modern language like C++. Why restrict yourself
to obscure academic languages when a freely available and widely used
language does what you need?
The irony is that this problem starts in CS departments where kids are still
taught to use 'char *' instead of a string class.
--
>> Cold blooded attack on civilians - http://italia.indymedia.org <<
Rave: Immanentization of the Eschaton in a Temporary Autonomous Zone.
Real world computer problems solved without expensive buzzwords-
My consulting resume http://www.farviolet.com/~entropy/resume2001.txt
Chris Torek
Ted Dennison <denn...@telepath.com> writes:
>Raj pretty much had the right of it. Exploitable buffer overflows are
>a known *class* of bugs that are pretty much endemic with C (and C++
>that uses C) code.
And other languages that offer interfaces to existing C (and C++)
libraries, for instance.
>On the other hand, you actually have to go fairly far out of your way
>to get an exploitable buffer overflow out of Ada code. ... [ref to
>site with ways to exploit Windows bugs elided]
Ultimately, this boils down to an indisputable fact: people are
exploiting buffer overflows that exist because poorly written C
code is popular. But this practically begs for a new question: if
poorly-written Ada (or any other language) were popular instead,
would that mean there would be *no* exploitable bugs? Or would the
exploitable bugs take some other form entirely? Perhaps, if the
world were different, someone would be posting to comp.lang.ada an
article saying: "If only Zerble were the popular language, these
bugs would not be resulting in all these worms and viruses." :-)
(Over here in comp.lang.c, I just try to convince people that
writing exploitable bugs is a bad idea.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
El Cerrito, CA, USA Domain: to...@bsdi.com +1 510 234 3167
http://claw.eng.bsdi.com/torek/ (not always up) I report spam to abuse@.
Matthias Blume
>
> In article <made-on-a-macint...@usenet.l1t.lt>,
> Daniel Fischer <d...@gueldenland.de> wrote:
> >> The buffer overflow occurs because of an old and well known bug in the C
> >> libraries.
>
> What does this have to do with C++? Any decent C++ programmer is using
> std::string instead of char *.
>
> >> Using Ada or another modern language like Ocaml or Mozart could have
> >> prevented this, thus stopping the worm before it infected the very first
> >> IIS server.
> > ~~~
>
> Or use of the features of a modern language like C++. Why restrict yourself
> to obscure academic languages when a freely available and widely used
> language does what you need?
Because some of those obscure academic languages do not suck so badly.
> The irony is that this problem starts in CS departments where kids are still
> taught to use 'char *' instead of a string class.
The real irony is that the trouble is with CS departments where there is a choice
between using 'char *' and 'std::string' because it means that kids at such departments
are taught in C++. C++ has to be about the worst choice for a teaching language.
Not to mention that real work gets done (and gets done well) in those obscure
academic languages, too. They are hardly a "restriction". In fact, if you had ever
given one of them a serious try, you might have found the experience liberating.
Regards,
Matthias
PS: By the way, the root of the problem is not fully solved by std::string.
Neither C nor C++ are "safe" languages and no amount of library hacking can make this
fact completely go away. (Of course, Ada isn't safe either.)
Marin David Condic
in all software regardless of language of implementation. If on average the
number of bugs in a large body of applications written in Assembler, C, C++,
Ada and Zerble were constant in both quantity and quality, (just taking
different forms) then there wouldn't be much point in injecting any sort of
language checks to prevent bugs. This seems kind of obviously silly - checks
put into languages to find and prevent bugs do have some impact on the
overall number of bugs. (Granted, we're talking about statistical averages -
maybe the Ada code I write is really crappy in comparison to the C code you
write and so for a similar effort on our parts, you may have fewer bugs. But
that's hardly the point.)
FWIW, I did a study at one time with metrics collected over a ten year span
of time comparing Ada development versus development in a variety of other
languages. There was a reduction in errors by a factor of four. Same
programmers, different projects. There is quite a bit of evidence to
indicate that errors can be reduced by language checks. That has practical
implications in terms of profits and losses.
Check out:
http://www2.dynamite.com.au/aebrain/ADACASE.HTM
http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp
http://www.rational.com/products/whitepapers/337.jsp
There you will find additional evidence that language choice *does* make a
difference in terms of productivity and defects.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Chris Torek" <to...@BSDI.COM> wrote in message
news:9k9if8$rn3$1...@elf.eng.bsdi.com...
Micah Cowan
> On Wed, 1 Aug 2001 09:09:12 -0400, Mike Smith wrote:
>
> > The buffer overflow occurs because of a bug in the *Microsoft* C library.
> > This is not endemic to C or C++ in general.
>
> The point is that if you look at the security bugs in Linux or Microsoft
> software they consists mainly of buffer overflow bugs. This comes from
> using languages such as C and C++ which allow buffer overflow due to
> their design. Other languages eliminate this problem to a large extent.
And implementations for these other languages are typically written in
what? Hm?
If you confine yourself to safe string use, you will have no
difficulties. Power always comes at the risk of its abuse. So?
"Modern" languages such as, oh, say Perl and Python, have no known
buffer overflow problems. But what did the authors use to implement
them with? So, if these buffer-stable languages are implemented in
"unsafe" languages such as C and C++; how were they able to write
"safe" language implementations in them? Oh! Oh! Pick me! I know!
...careful design and programming (good ideas for any language).
Micah
--
"Everytime you declare main() as returning void - somewhere a little
baby cries. So please, do it for the children." -- Daniel Fox
Kaz Kylheku
>Or use of the features of a modern language like C++. Why restrict yourself
>to obscure academic languages when a freely available and widely used
>language does what you need?
>
>The irony is that this problem starts in CS departments where kids are still
>taught to use 'char *' instead of a string class.
Someone who is too clueless to correctly program in a language like C
should not be writing critical software in any language. Low level data
representation details being taken care of, the programmer will simply
focus his or her lack of discipline and skill to some other area.
Saying that a better language will prevent errors is like saying that
installing video cameras in a neighborhood stops crime. That is a fallacy;
the crime is simply displaced to where there are no cameras.
Higher level languages are advantageous because of the greater ease
in which complex problems can be represented using fewer lines of
code that is more easily adapted to changing requirements. They don't
compensate for bad programming.
Also note that even with classes like std::string, C++ still provides
enough proverbial rope. For example, references can be bound to automatic
objects which are deleted when their statement block terminates, and
then those references can continue to be used. Uses of the ``safe''
operators new and delete can lead to memory leaks or the use of dangling
pointers. Even there there are pathatic pitfalls, like using delete []
with new or delete with new []. All kinds of pitfalls for the unwary exist
in C++ that are not inherited from C, like calling a virtual function
in a base class constructor, expecting to reach the derived one; adding
a new virtual function to a base class which happens to match the name
and type signature of an existing function in a derived class; deleting
through a base class that lacks a virtual destructor.
It's trivial to write a diagnostic-free program in this ``modern
language'' that contains horrible errors and is grossly non-portable.
Lastly, note that when you write real-world software in C++, you cannot
avoid interfacing with C libraries, which sometimes require you to use
C arrays. For instance, you can't read data from a socket directly into
a C++ buffer class. At some point you have to expose a low level buffer,
which is just a piece of memory, and pass the size of that buffer as
a separate parameter.
Mike Smith
news:L5Y97.14163$ar1....@www.newsranger.com...
>
> I found a mirror which folks like me behind facist firewalls may have an
easier
> time accessing.
http://www.supportamerica.com/win_buff/win_buff_overflow.html .
> If you don't understand the buffer overflow problem (which apparently, at
least
> Mike doesn't)
Yes, I do. However, what I also understand is that buffer overflow problems
are a *bug*, not a "feature", and they are a bug in the *application code*,
not the language. Only improperly written C code can contain buffer
overflow problems, and there is absolutely *no* excuse for finding them in
C++ code, because the STL can be used to eliminate them completely.
--
Mike Smith
Florian Weimer
> Ultimately, this boils down to an indisputable fact: people are
> exploiting buffer overflows that exist because poorly written C
> code is popular. But this practically begs for a new question: if
> poorly-written Ada (or any other language) were popular instead,
> would that mean there would be *no* exploitable bugs?
The problem with buffer overflow bugs is that they are very hard to
discover if the first audit occurs after the software has been out
for years (and changed many times, by different persons). If you're
coding from scratch, you can try to follow a rule that it must be
obvious that there aren't any such problems, but that's not an option
with existing code, and not many people seem to follow this route
anyway.
Other C-eminent problems (for example, bugs related to improper use
of format strings) can be checked for almost automatically, so they
aren't such a big problem.
Other kinds of defects still have the potential of being very severe
(for example, look at the recent problem with SSH 3.0.0). My
subjective impression is that remote code injection attacks usually
have far more potential for harm than these other defects, but this
observation might just reflect the fact that in the latter cases, the
impact of the vulnerability varies much more from defect to defect.
Marin David Condic
1) This is the "Any *competent* programmer would/wouldn't...." answer that I
do not find satisfying. We are all incompetent on any given hour of any
given day and we make simple, boneheaded mistakes that can be automatically
caught by a machine and prevented from escaping into the final product.
Whats wrong with that? Arguing that this is just going to force the bugs off
into some other area is a rather pessimistic view that treats bugs like they
were subject to gas laws - they can't be created or destroyed, only
relocated. ("In this house we obey the laws of thermodynamics!" -- Homer
Simpson :-) This seems to be absurd on the face of it. If that were true, we
should devote no effort whatsoever to bug prevention of any kind because it
would be wasted.
2) I personally did a study of defects on data collected over a ten year
timespan that compared defect rates when using Ada versus defect rates using
a number of other languages. The Ada projects had defect rates that were
lower by a factor of four. Saying that language of implementation has no
impact on the number of defects flies in the face of emperical evidence to
the contrary & I would ask that such claimants back that up with something
bordering on scientific evidence rather than rectal extraction. I have good
evidence that indicates languages *do* reduce errors by a very significant
amount. Not just my own study - try these links:
http://www2.dynamite.com.au/aebrain/ADACASE.HTM
http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp
http://www.rational.com/products/whitepapers/337.jsp
It may be that any given Ada program/programmer is going to be more
bug-ridden than some other program written in C/C++ by a "competent"
programmer. However, in the important business of making money for the
stockholders, I believe that we should use every technical advantage we can
get rather than relying on "competence" (which I doubt exists 100% of the
time in any of us). If a safer language like Ada exists and all other
considerations are equal, I'd think it was important to choose Ada and
reduce errors accordingly.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:BUZ97.2587$B37.1...@news1.rdc1.bc.home.com...
Ed Falis
> > The point is that if you look at the security bugs in Linux or Microsoft
> > software they consists mainly of buffer overflow bugs. This comes from
> > using languages such as C and C++ which allow buffer overflow due to
> > their design. Other languages eliminate this problem to a large extent.
>
> And implementations for these other languages are typically written in
> what? Hm?
Machine code for Ada. Hm?
- Ed
Dale Stanbrough
> Yes, I do. However, what I also understand is that buffer overflow problems
> are a *bug*, not a "feature", and they are a bug in the *application code*,
> not the language. Only improperly written C code can contain buffer
> overflow problems, and there is absolutely *no* excuse for finding them in
> C++ code, because the STL can be used to eliminate them completely.
Ah, that's the solution! Lets just write -proper- code.
Chain saw guards - not needed, just use them properly!
Seat belts - not needed, just drive properly!
Languages with checks - not needed - just code properly!
Condoms ..., er, um....
Dale :-)
Ed Falis
>
> In article <9k9if8$rn3$1...@elf.eng.bsdi.com>,
> Chris Torek <to...@BSDI.COM> wrote:
>
> > But this practically begs for a new question: if
> > poorly-written Ada (or any other language) were popular instead,
> > would that mean there would be *no* exploitable bugs?
>
> explode, and fall down. Hmmm... didn't that happen a while ago?
>
> --
> Göran Larsson Senior Systems Analyst hoh AT approve DOT se
Read the report.
- Ed
Larry Kilgallen
> Well, that's rather assuming that there will be some constant level of bugs
> in all software regardless of language of implementation. If on average the
> number of bugs in a large body of applications written in Assembler, C, C++,
> Ada and Zerble were constant in both quantity and quality, (just taking
> different forms) then there wouldn't be much point in injecting any sort of
> language checks to prevent bugs. This seems kind of obviously silly - checks
> put into languages to find and prevent bugs do have some impact on the
> overall number of bugs. (Granted, we're talking about statistical averages -
> maybe the Ada code I write is really crappy in comparison to the C code you
> write and so for a similar effort on our parts, you may have fewer bugs. But
> that's hardly the point.)
A minor point is that I cannot figure out whether Marin or Chris is the
one more likely to write bug-free code.
A major point is that neither can Microsoft.
At a 50,000 foot level, it is better to equip the troops with tools that
have safety guards on them. They may remove the guards from time to time,
but that is better than for a giant corporation to pretend it is capable
of only hiring people who are so skilled that they would never need a
safety guard.
Chris Torek
>in all software regardless of language of implementation.
No, not at all. I agree that there are (more or less) objective
measures that show that the defect rate in some languages (e.g.,
Ada) is far lower than the defect rate in other languages (C,
assembler, etc). I will even agree with one who argues that it
would be harder to break into a system with 100 defects than one
with 1000. But as far as actual breakins go:
>There you will find additional evidence that language choice *does*
>make a difference in terms of productivity and defects.
Until you get the number of defects close to zero -- I am not sure
"how close" is required; obviously zero suffices, given an appropriate
definition of defects; but I think zero is also unachievable unless
given an inappropriate definition :-) -- there will still be
"exploitable bugs" in systems. My argument is that, if we somehow
achieved this more perfect world, the crackers would simply change
their tactics: instead of using easily-cracked buffer overflow
bugs, they would use more-difficult (but available today) tricks
like TCP session record and replay.
The "real world" analogy of locks is useful here. Locks can keep
"mostly-honest" people honest, and the better the locks, the greater
this effect becomes. It is certainly foolish to say: "well, this
cheap lock does not stop some thieves, therefore we should eliminate
all locks" -- but it is equally foolish to say "aha, this more-expensive
lock stopped that particular thief, therefore we should all just
use this lock and decree perfection".
In other words, I do not dispute that code written in Ada tends to
be better; I just think it is a mistake to go from there to "if
only Microsoft wrote in Ada, there would be no more Code-Reds."
Kaz Kylheku
Stanbrough wrote:
>Mike Smith wrote:
>
>> Yes, I do. However, what I also understand is that buffer overflow problems
>> are a *bug*, not a "feature", and they are a bug in the *application code*,
>> not the language. Only improperly written C code can contain buffer
>> overflow problems, and there is absolutely *no* excuse for finding them in
>> C++ code, because the STL can be used to eliminate them completely.
>
>
>Ah, that's the solution! Lets just write -proper- code.
>
>Chain saw guards - not needed, just use them properly!
>Seat belts - not needed, just drive properly!
Can you drive improperly or saw improperly because of the presence of
safety features?
>Languages with checks - not needed - just code properly!
An analogy for this is the use of video cameras to prevent crime.
In reality, cameras only displace crime to location without cameras.
Languages with checks are great, but they don't compensate for bad
programming. What they do is displace bad programming. Programmers
are displaced to causing other types of errors, or maybe they are
displaced to other programming languages entirely.
If programs in some language tend to demonstrate more robustness than
programs in some other language, is it due to the language, or is it
due to the types of people that gravitate toward using these languages?
I suspect that if Microsoft wrote IIS in Caml, Lisp or Ada, using the same
developers, it would still have security holes. They would not be the
same holes, revolving around the injection of a machine language through
a buffer overflow, but I'm sure they could figure out some creative
ways of screwing up.
Dan Cross
Mike Smith <smi...@michaelsmithHATESSPAM.org> wrote:
>Yes, I do. However, what I also understand is that buffer overflow problems
>are a *bug*, not a "feature", and they are a bug in the *application code*,
>not the language. Only improperly written C code can contain buffer
>overflow problems, and there is absolutely *no* excuse for finding them in
>C++ code, because the STL can be used to eliminate them completely.
Well, the same could be said of assembly language programming, but do
we program major software systems in assembler? And of course it's
tautological that only erroneous programs have bugs.
However, just because we can use a tool effectively doesn't mean that's
the tool to use. I could use a chainsaw to cut my butter in the
morning when I put it on my bagel, but it's a lot safer and easier to
use a butter knife instead. A similar analogy can be drawn with
software; just because someone can write correct C code on a large
software system doesn't mean they should. I mean, why should they? If
it's easier and less error-prone to use, say, Ada (or Eiffel, or ...)
why not make use of those languages instead?
One reason might be, ``well, I like C.'' Hey, that's great; I like C
too (heavens forbid! :-); it's absolutely great as a low-level systems
programming language. But I don't like using it for application
programming, because I think it lacks a lot of useful higher-level
concepts that make application programming easier (ie, a built in first
class string type, built in ADT's, true strong typing, etc). It's a
pain to implement those again and again, but it also makes no sense to
add them to C since other languages already have those facilities. I
don't need or want C to have all those things, because then it becomes
less effective for systems programming.
People tend to forget that a programming language is a tool, and no
single tool is appropriate for every job (you don't put in a screw with
a hammer, do you? You do? Watch out for your house falling over,
then. :-). Programmer's in particular tend to develop an almost
religious devotion to their tools, so we end up with major software
applications written in C when they could be written much more
profitably in something like Ada (or ML, Lisp, Prolog, Eiffel, Python
or whatever).
So, in summary, an old cliche is apropos: pick the best tool for the
job. Often, when analyzing what one is doing, one will find that C
isn't that tool. Sometimes it is, but it depends on the context.
As specifically regards applications programming, it's been my
experience that C isn't usually the best choice. Those who believe
that moving to other languages won't eliminate buffer overflows are
probably correct, but I submit that they would be greatly diminished,
and the empirical evidence backs me up.
- Dan C.
Micah Cowan
Fine. And machine code doesn't have the potential for buffer overflow
problems, I presume?
Markus Mottl
> randho...@pvv.org (Preben Randhol) writes:
>> The point is that if you look at the security bugs in Linux or Microsoft
>> software they consists mainly of buffer overflow bugs. This comes from
>> using languages such as C and C++ which allow buffer overflow due to
>> their design. Other languages eliminate this problem to a large extent.
> And implementations for these other languages are typically written in
> what? Hm?
Any language that attempts to be called serious bootstraps
itself. Needless to say that the first compiler of a new language wasn't
written in the language itself, but the same holds true for C/C++...
> If you confine yourself
I prefer being confined by the compiler. It's usually less sleepy than I.
> "Modern" languages such as, oh, say Perl and Python,
"New": yes, "modern": no.
> have no known buffer overflow problems. But what did the authors
> use to implement them with? So, if these buffer-stable languages are
> implemented in "unsafe" languages such as C and C++; how were they able
> to write "safe" language implementations in them? Oh! Oh! Pick me!
> I know!
Simple: after years of bug chasing and endless support by legions of
users with bug reports, these issues have finally been solved...
> ...careful design and programming (good ideas for any language).
A sound type system and an expressive language: good ideas for any
language ;)
Regards,
Markus Mottl
--
Markus Mottl, mo...@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
Dan Cross
Kaz Kylheku <k...@ashi.footprints.net> wrote:
>>Chain saw guards - not needed, just use them properly!
>>Seat belts - not needed, just drive properly!
>
>Can you drive improperly or saw improperly because of the presence of
>safety features?
Sure you can! But the incidences of people chopping off their fingers
or being thrown through windshields went way down once chainsaw guards
and seat belts came into widespread use.
>>Languages with checks - not needed - just code properly!
>
> [...]
>
Hmm, I sort of read your note as, ``well, these things don't prevent
all errors, so why bother with them?'' Well, nothing prevents all
errors, but Chris Torek was spot on with his analogy with locks. A
small lock isn't going to stop a professional thief with lock pick
tools, but does that mean we should throw away all the locks we use?
Personally, anything that allows me to do away the minutia that one has
to keep track of when programming in a language like C is a good
thing. If I can push some of the effort in that arena onto the
language and runtime system, that's a big win.
Once again, it comes back to picking the right tool for the job. When
I need to worry about the minutia (ie, in an operating system), C is
right there for me. When I don't, I have other options.
- Dan C.
Dale Stanbrough
> Languages with checks are great, but they don't compensate for bad
> programming.
Well, I suspect that this is purely conjecture on your part. My equally
valid conjecture (actually possibly better, because I've seen lots
of students use C and Ada) is that better languages do result in
better code. Errors in code (such as array overflow) is removed.
The code that is produced generally has fewer of these problems
(because they are picked up earlier, and are removed from
the program).
Perhaps I should ask you this question...
Would you be happy if the C language went back to not
enforcing/type checking parameters to functions?
What they do is displace bad programming. Programmers
> are displaced to causing other types of errors, or maybe they are
> displaced to other programming languages entirely.
Again this is simply conjecture, with I would guess, little evidence.
> If programs in some language tend to demonstrate more robustness than
> programs in some other language, is it due to the language, or is it
> due to the types of people that gravitate toward using these languages?
Why are you asking this question, if above you state that such
languages -don't- compensate for bad programming? I don't think
you can have it both ways...
Dale
Richard Heathfield
>
<snip>
>
> Any language that attempts to be called serious bootstraps
> itself. Needless to say that the first compiler of a new language wasn't
> written in the language itself,
Just a small nit - there's nothing to stop you writing the first
compiler of a new language using an interpreter for that language. I
agree that you can't write the first *implementation* of a language in
itself, though. (Or at least, if you can, you are probably related to
Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
too.)
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Larry Kilgallen
> Until you get the number of defects close to zero -- I am not sure
> "how close" is required; obviously zero suffices, given an appropriate
> definition of defects; but I think zero is also unachievable unless
> given an inappropriate definition :-) -- there will still be
> "exploitable bugs" in systems. My argument is that, if we somehow
> achieved this more perfect world, the crackers would simply change
> their tactics: instead of using easily-cracked buffer overflow
> bugs, they would use more-difficult (but available today) tricks
> like TCP session record and replay.
If those other tactics are more difficult, it means productivity
(in the cracking business) is lower using those tactics. Otherwise
those tactics would be in wider use today. Perhaps they are even
less easily spread to Script Kiddies.
Kaz Kylheku
>Markus Mottl wrote:
>>
><snip>
>>
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,
>
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though.
However, you can write that implementation in another language that is
arbitrarily close to that language. For example, an implementation of C
can be written in a variant of the C language which doesn't support the \v
escape sequence in character and string literals. That implementation's
source code can then be corrected to use those literals where necessary,
so that for instance when it parses the \v sequence, the value that is
substituted is expressed as '\v'.
In this manner, you can start with some little language and then hack
more and more features into it, feeding them back into its own
source code.
>Or at least, if you can, you are probably related to
>Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
>too.
Or more likely, you *are* Thompson, Knuth, or Hofstadter. :)
Markus Mottl
> Markus Mottl wrote:
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,
> Just a small nit - there's nothing to stop you writing the first
> compiler of a new language using an interpreter for that language. I
> agree that you can't write the first *implementation* of a language in
> itself, though. (Or at least, if you can, you are probably related to
> Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
> too.)
That's what I meant ("implementation" rather than "compiler"), but I was
thinking of languages that do not have interpreters (e.g. C), though in
theory interpreters are possible for any language.
Aaron Denney
> (you don't put in a screw with
> a hammer, do you? You do? Watch out for your house falling over,
> then. :-).
Actually... there are some screws that are supposed to be hammered in. The tip
is smooth like a nail, but the ridges gradually grow. AIUI, they are a variant
of the nails with screw threads in a similar pattern. The screws can be fairly
easily removed; the nails can't.
--
Aaron Denney
-><-
Aaron Denney
> That's what I meant ("implementation" rather than "compiler"), but I was
> thinking of languages that do not have interpreters (e.g. C), though in
> theory interpreters are possible for any language.
C has a few interpreters for it, actually. (Well, some are not quite C, or
don't implement everything.)
CINT, EiC, and ICI seem to be the most popular ones. I've used one
in a job a few years back that was an extension language. It was nice
because if the interpreted version wasn't fast enough, you could compile the
extension and load it as a dll. (I don't recall the name, and it was hacked by
the company to export our own bindings. The only non-compliance I had found was
that adjacent string literals were not merged.)
Darren New
> Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
> too.)
Reminds me of a comment I saw in the Hermes distribution, something
along the lines of
"This is hand-compiled to bootstrap the compiler. Do not touch this. You
don't know what you're doing. Only Bill knows what he's doing. Bill is
God."
So yes, the other way is to hand-emulate the compiler you wrote to
figure out what it would generate. :-)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dn...@san.rr.com
Only a WIMP puts wallpaper on his desktop.
Michael Rubenstein
<bin...@eton.powernet.co.uk> wrote:
>Markus Mottl wrote:
>>
><snip>
>>
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,
>
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though. (Or at least, if you can, you are probably related to
>Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
>too.)
In fact that's how the first Lisp compiler was written. The
interpretter was written first, the compiler was written in Lisp
and then used in the interpretter to compile itself.
--
Michael M Rubenstein
those who know me have no need of my name
>I was thinking of languages that do not have interpreters (e.g. C), though
>in theory interpreters are possible for any language.
--
okay, have a sig then
Mike Smith
news:9ka0on$m...@augusta.math.psu.edu...
> In article <tmgrs9a...@corp.supernews.com>,
> Mike Smith <smi...@michaelsmithHATESSPAM.org> wrote:
> >Yes, I do. However, what I also understand is that buffer overflow
problems
> >are a *bug*, not a "feature", and they are a bug in the *application
code*,
> >not the language. Only improperly written C code can contain buffer
> >overflow problems, and there is absolutely *no* excuse for finding them
in
> >C++ code, because the STL can be used to eliminate them completely.
>
> Well, the same could be said of assembly language programming, but do
> we program major software systems in assembler? And of course it's
> tautological that only erroneous programs have bugs.
Define "major". Is the software for automotive engine computers written in
Ada? The embedded world is one of the most "major" categories of software
development, and I'd bet that a lot of that is in fact written in assembly.
--
Mike Smith
There are perhaps 5% of the population that simply *can't* think.
There are another 5% who *can*, and *do*.
The remaining 90% *can* think, but *don't*.
-- R. A. Heinlein
Bruce G. Stewart
> Any language that attempts to be called serious bootstraps
> itself. Needless to say that the first compiler of a new language wasn't
> written in the language itself, but the same holds true for C/C++...
Perhaps this is true of any language that aspires to be suitable for
writing compilers. It would be silly to restrict onself to writing, say,
an SQL statement compiler as an SQL statement.
Kaz Kylheku
Note that everything that SQL does could be expressed in a serious
language that bootstraps itself. E.g. a Lisp form could represent a
structured query. So the existence of a dedicated language just for
database queries is superfluous.
Ed Falis
Sorry, I misunderstood your initial remark. Most Ada compilers are
written in Ada, and produce machine code. I thought you were saying
they were implemented using C as an intermediate form. You can get off
your high hobby horse now.
- Ed
gr...@cs.wa.edu.au
:>Markus Mottl wrote:
:>> Any language that attempts to be called serious bootstraps
:>> itself. Needless to say that the first compiler of a new language wasn't
:>> written in the language itself,
: arbitrarily close to that language. For example, an implementation of C
: can be written in a variant of the C language which doesn't support the \v
: escape sequence in character and string literals. That implementation's
: source code can then be corrected to use those literals where necessary,
: so that for instance when it parses the \v sequence, the value that is
: substituted is expressed as '\v'.
If you start with assembler, this process will lead to C very quickly. :)
-Greg
David Starner
news:WG3a7.3350$B37.1...@news1.rdc1.bc.home.com...
Sure, you can hack a database query language unto the side of any "serious"
language, and implement it. You've then spent much time implementing a
"serious" language and a little time writing a database query language,
which is all you really needed. Oh, and now you need to filter all queries
coming into your database, because they can include arbitrary code.
Yes, the existance of a dedicated language just for database queries is
superfluous. So is the existance of all programming languages but one - you
can do everything in BASIC, or JOVIAL, or BLISS. Woo hoo.
--
David Starner - dstar...@aasaa.ofe.org
"The pig -- belongs -- to _all_ mankind!" - Invader Zim
Warren W. Gay VE3WWG
> Kaz Kylheku wrote:
> > Languages with checks are great, but they don't compensate for bad
> > programming.
>
> Well, I suspect that this is purely conjecture on your part. My equally
> valid conjecture (actually possibly better, because I've seen lots
> of students use C and Ada) is that better languages do result in
> better code. Errors in code (such as array overflow) is removed.
> The code that is produced generally has fewer of these problems
> (because they are picked up earlier, and are removed from
> the program).
>
> Perhaps I should ask you this question...
>
> Would you be happy if the C language went back to not
> enforcing/type checking parameters to functions?
I have programmed in "B" ages ago, and it was virtually typeless
(there was a distinction made for floating point values). I can
tell you, the only thing that was worse to debug, was assembly
language! Everything (but floats) were a word (on the Honeywell,
that was a 36-bit word). To work with strings you did procedure
calls... what a nightmare to debug.
When C came along, it was a blessing. Why? Stronger type checking
and other "language safeguards".
But today, C is the "B" of yesteryear. Ada is a big improvement
over C, even C++ and yes, Java.
--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg
Fergus Henderson
>Markus Mottl wrote:
>>
>> Any language that attempts to be called serious bootstraps
>> itself. Needless to say that the first compiler of a new language wasn't
>> written in the language itself,
>
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though.
Sure you can, you just need to write in a subset of the language
that happens to *also* be valid in some other language.
For example, for the first implementation of the Mercury compiler,
we wrote it in the intersection of Mercury and Prolog;
we used a Prolog compiler to compile the first version, but the source
was also valid Mercury code, so we were then able to bootstrap
using the same sources.
I wouldn't be surprised if Bjarne Stroustrup did a similar thing with Cfront,
writing it in the intersection of C and "C with classes".
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Chris Kuan
>I wouldn't be surprised if Bjarne Stroustrup did a similar thing with
>Cfront, writing it in the intersection of C and "C with classes".
D&E 3.3 ("Cfront") states that "Cfront was originally written in C with Classes
and soon transcribed into C84 so that the very first working C++ compiler was
entirely done in C++".
--
Chris Kuan, CSC (Australia)
Concatenate for email: mr gazpacho @ hotmail . com
"Law is a repository for the aimlessly clever" - Tim Freedman
Kaz Kylheku
>Kaz Kylheku <k...@ashi.footprints.net> wrote in message
>news:WG3a7.3350$B37.1...@news1.rdc1.bc.home.com...
>> In article <3B68C447...@worldnet.att.net>, Bruce G. Stewart wrote:
>> >Markus Mottl wrote:
>> >
>> >> Any language that attempts to be called serious bootstraps
>> >> itself. Needless to say that the first compiler of a new language
>wasn't
>> >> written in the language itself, but the same holds true for C/C++...
>> >
>> >Perhaps this is true of any language that aspires to be suitable for
>> >writing compilers. It would be silly to restrict onself to writing, say,
>> >an SQL statement compiler as an SQL statement.
>>
>> Note that everything that SQL does could be expressed in a serious
>> language that bootstraps itself. E.g. a Lisp form could represent a
>> structured query. So the existence of a dedicated language just for
>> database queries is superfluous.
>
>Sure, you can hack a database query language unto the side of any "serious"
>language, and implement it.
If that language is Lisp or something like it, then you only have to
write code in that language; you don't have to hack the language. That's
because the parser is available to you; you can call on it to parse and
give you the resulting structure.
>You've then spent much time implementing a
>"serious" language and a little time writing a database query language,
>which is all you really needed.
You are assuming that everything is done from scratch: first the
implementation language and then the query language. If that is the case,
it's a lot of work no matter what.
But suppose the implementation language is already available, and your
job is only to write a database language. Then depending on what kind of
implementation language you have, the difficulty of your task will vary.
>Oh, and now you need to filter all queries
>coming into your database, because they can include arbitrary code.
In Lisp, there is already a parser built in that will give you a tree.
That tree could be code or data; the representation is uniform. You can
process that tree. That's a labor saving right there; not having to write
a parser, just worry about the structure that pops out. That structure
could support an arbitrarily complex syntax for representing queries.
Think about all the time wasted implementing parsers for all these silly
data formats like SQL and XML, when there is a programming language that
can uniformly handle structured data in its own syntax: query languages,
markup languages, you name it.
Ketil Z Malde
> Languages with checks are great, but they don't compensate for bad
> programming. What they do is displace bad programming. Programmers
> are displaced to causing other types of errors, or maybe they are
> displaced to other programming languages entirely.
This is, to me, a very surprising statement. (In fact, I would have
thought that if the language let you take your mind off the minute and
irrelevant details like array bounds checking, it would leave more
mind share to other areas of the program.) Could you please cite some
references for this? Or at least a rationale behind it?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Richard Heathfield
>
> [...] I was
> thinking of languages that do not have interpreters (e.g. C), though in
> theory interpreters are possible for any language.
As well as the other C interpreters people have mentioned in reply to
this, there was also one released by HiSoft for the Atari ST, which I
half-remember with great fondness.
Preben Randhol
> In article <3B687EDF...@mediaone.net>,
> Ed Falis <efa...@mediaone.net> wrote:
>
>> Read the report.
>
> I have. Your point is?
Perhaps read it again.
Preben
--
«Don't use C; In my opinion, C is a library programming language
not an app programming language.» - Owen Taylor (GTK+ developer)
Use Ada 95, a free language. More info at http://www.adapower.com/
Preben Randhol
>
> If you confine yourself to safe string use, you will have no
> difficulties. Power always comes at the risk of its abuse. So?
Again with the if. Why should one waste time on checking the code for
buffer overflow errors (which are so numerous in both M$ and Linux
software that some alarm bells ought to go off even for C/C++ fans) when
the language does it for you. Especially when you think that most
software are developed by several people, over time. You don't have
_one_ person that knows all the code. The code usually evolves.
Bill Godfrey
> Define "major". Is the software for automotive engine computers written in
> Ada? The embedded world is one of the most "major" categories of software
> development, and I'd bet that a lot of that is in fact written in assembly.
IME, assembly only really gets a look in when the thing powers up and
the registers need fiddling with, and wrappers around interrupt handling.
Once the bit which has to be in assembly is dealt with, it's a quick
JSR to a C function.
Other people's experiences may vary...
Bill, likes assembly code. (gcc -S is useful.)
Zoltan Somogyi
>Just a small nit - there's nothing to stop you writing the first
>compiler of a new language using an interpreter for that language. I
>agree that you can't write the first *implementation* of a language in
>itself, though. (Or at least, if you can, you are probably related to
>Ken Thompson, Donald Knuth, Alan Turing, and perhaps Douglas Hofstadter
>too.)
The Melbourne Mercury compiler is the first (and so far only) implementation
of the Mercury language, and it is written in Mercury. During the bootstrapping
period, we confined ourselves to the intersection of Mercury and Prolog, and
used a Prolog implementation to execute the compiler. None of us are related
to any of those people as far as I know. :-) This is an exception from your
rule, because the first "implementation" of Mercury was in Mercury as well as
in Prolog. What counts is not whether the first implementation is in its own
language, but whether it is (also) in a language that already has an
implementation.
The other exception to your rule is that one can write the first compiler for
language X in language X itself, and hand-tranlate that to machine code.
People don't usually call hand-translation an "implementation", and thus
the compiler remains the first "implementation" of language X. Most people
wouldn't call this approach feasible, but theoretically its feasibility
is limited only by the hand-translator's patience ... :-)
Zoltan Somogyi <z...@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science and Software Engineering, Univ. of Melbourne
Richard Bos
> In article <Xz%97.2632$B37.1...@news1.rdc1.bc.home.com>,
> Kaz Kylheku <k...@ashi.footprints.net> wrote:
> >>Chain saw guards - not needed, just use them properly!
> >>Seat belts - not needed, just drive properly!
> >
> >Can you drive improperly or saw improperly because of the presence of
> >safety features?
>
> Sure you can! But the incidences of people chopping off their fingers
> or being thrown through windshields went way down once chainsaw guards
> and seat belts came into widespread use.
Yes, and the seat belt actually nicely illustrates Kaz's point.
Immediately after the seat belt was introduced, the number of fatalities
in accidents plummeted.
The years after, the number slowly rose again, because drivers adapted
to the new safety level seat belts provided and were willing to take
risks they wouldn't have taken without them.
The nature of the fatalities have changed, yes. Nowadays, it's mostly
innocent bystanders that get killed, not the driver that flies through
the windscreen.
Richard
Richard Bos
> A minor point is that I cannot figure out whether Marin or Chris is the
> one more likely to write bug-free code.
I have no idea how good Marin is, but I'd trust Chris's code over, well,
almost anyone's. Certainly including my own. The reason? I've seen some
of Chris's code in the past, and it is generally as bug-free as any code
I've seen in any language.
Richard
Richard Bos
> Would you be happy if the C language went back to not
> enforcing/type checking parameters to functions?
No. Because checking parameter passing can be done, and takes time only,
at compile-time. Checking array bounds has an impact on the performance
of the program itself.
Oh, btw, there _are_ bounds-checking compilers for C. They get used
where the extra safety is deemed important enough to justify the loss of
speed.
Richard
Markus Mottl
> CINT, EiC, and ICI seem to be the most popular ones.
I knew about CINT, which actually interprets C++ and is heavily used in
CERN's ROOT-project (data visualization). One can get pretty far with
those interpreters (at least with CINT). Still, I wouldn't say that
C/C++-interpreters are anywhere close to being commonly used. Other
languages lend themselves to interpretation much more easily.
Markus Mottl
> Perhaps this is true of any language that aspires to be suitable for
> writing compilers. It would be silly to restrict onself to writing,
> say, an SQL statement compiler as an SQL statement.
I think the context of the thread makes it clear that we are considering
"universal" programming languages only, not in the sense of computational
power but practical applicability.
Richard Bos
> The irony is that this problem starts in CS departments where kids are still
> taught to use 'char *' instead of a string class.
No, the irony is that this problem does indeed start in CS departments,
because students[1] are taught in C++ and Ada, because these can be used
to teach safely and easily - which is good - but _not_ beyond that, into
"what can actually go wrong" territory - which is not good. The result
is too many students who leave not knowing about such things as possible
overflow, and thus don't know how to avoid it. In this way, languages
designed to promote safer programming actually promote unsafer
programming, by not promoting knowledge about what _is_ unsafe.
Richard
[1] Since when, btw, is a student a "kid"?
Markus Mottl
> Immediately after the seat belt was introduced, the number of fatalities
> in accidents plummeted.
> The years after, the number slowly rose again, because drivers adapted
> to the new safety level seat belts provided and were willing to take
> risks they wouldn't have taken without them.
The number rose, because many more people (= more accidents, more traffic
= even more accidents) could afford ever faster cars and because the
percentage of professional (= skilled) drivers fell.
That says something about programming, too...
Martin Dowie
1) you can always turn these checks "off" for speed
2) there are constructs that will allow the compiler
to not insert them in the first place (e.g. using
<type_name>'Range when looping through an array
indexed by <type_name>
From what I remember of a Tucker Taft message a while
back there are considerations of making even more
checks compiler-time as opposed to run-time in Ada0Y
(e.g. some of the elaboration checks).
Richard Bos <in...@hoekstra-uitgeverij.nl> wrote in message
news:3b690549....@news.worldonline.nl...
Martin Dowie
Reliability Association) publish guidelines that indicate that
Ada should be considered in preference to using C for safety
critical systems. The report defines MISRA-C, a "safe" subset
of C.
Mike Smith <smi...@michaelsmith.NOSPAMorg> wrote in message
news:tmhe597...@corp.supernews.com...
[snip]
Larry Kilgallen
Try to extrapolate, then, to the situation where you don't know the
individual. Very few people are able to restrict their use of computer
software to that where they have personal knowledge of the individual.
Beelsebob
So your point is that you can use a buggy microsoft implementation of
C++ to write a virus.
Now then let me see... oh yes, you can use Ada (not even a buggy
implementation of it) to cause the Arian 5 rocket to try and turn
round in mid flight, and disintegrate into many tinny little burrning
pieces.....
Leif Roar Moldskred
In comp.lang.ada Beelsebob <tat...@cs.york.ac.uk> wrote:
[Snip]
> Now then let me see... oh yes, you can use Ada (not even a buggy
> implementation of it) to cause the Arian 5 rocket to try and turn
> round in mid flight, and disintegrate into many tinny little burrning
> pieces.....
That's right, sir. Unlike with other computer languages, when you
shoot yourself in the foot with Ada, you don't just get a measly
little pin-prick of a buffer-overflow. No sir, when you shoot yourself
in the foot with Ada - you blast it clean off at the knee!
(As an aside, I believe that the program was actually correct
(i.e. behaved according to specifications), but had been misapplied.)
--
Leif Roar Moldskred
"Ada - fewer, more _interesting_ bugs."
Ed Falis
>
> In article <3B687EDF...@mediaone.net>,
> Ed Falis <efa...@mediaone.net> wrote:
>
> > Read the report.
>
> I have. Your point is?
>
> Göran Larsson Senior Systems Analyst hoh AT approve DOT se
It was about inappropriately reused code. I suppose that does bolster
some of the arguments about poor programming, though the error in this
case was due to decisions pretty far upstream from the code.
- Ed
Charles Krug
I'm absolutly certain of my ability to write code to crash an Arian rocket in
ANY language . . . <VBG>
Where's our resident Eiffle advocate? Why hasn't he weighed in yet?
CBFalconer
>
... snip ...
>
> 2) I personally did a study of defects on data collected over a ten year
> timespan that compared defect rates when using Ada versus defect rates using
> a number of other languages. The Ada projects had defect rates that were
> lower by a factor of four. Saying that language of implementation has no
> impact on the number of defects flies in the face of emperical evidence to
> the contrary & I would ask that such claimants back that up with something
> bordering on scientific evidence rather than rectal extraction. I have good
> evidence that indicates languages *do* reduce errors by a very significant
> amount. Not just my own study - try these links:
>
> http://www2.dynamite.com.au/aebrain/ADACASE.HTM
> http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp
> http://www.rational.com/products/whitepapers/337.jsp
>
> It may be that any given Ada program/programmer is going to be more
> bug-ridden than some other program written in C/C++ by a "competent"
> programmer. However, in the important business of making money for the
> stockholders, I believe that we should use every technical advantage we can
> get rather than relying on "competence" (which I doubt exists 100% of the
> time in any of us). If a safer language like Ada exists and all other
> considerations are equal, I'd think it was important to choose Ada and
> reduce errors accordingly.
** PLEASE DO NOT top post **
I agree completely. However, the presence of "better" languages
does not prevent anyone using other languages, for whatever
reasons. The important thing is to recognize the flaws and
weaknesses of the chosen language, and to program in a defensive
manner. In C (and other languages) this means using assert
statements and "can't happen" clauses in appropriate places. It
also means NOT disabling run-time checks in languages that have
them (barring extreme performance needs).
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
CBFalconer
>
> Micah Cowan wrote:
>
> > > The point is that if you look at the security bugs in Linux or Microsoft
> > > software they consists mainly of buffer overflow bugs. This comes from
> > > using languages such as C and C++ which allow buffer overflow due to
> > > their design. Other languages eliminate this problem to a large extent.
> >
> > And implementations for these other languages are typically written in
> > what? Hm?
>
> Machine code for Ada. Hm?
I think you will find that GNU Ada is written in GNU Ada. I KNOW
that PascalP is written in Pascal. Neither is totally bug free,
although at time of release they were IMHO free of *known*
undocumented bugs.
CBFalconer
>
> Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
> > That's what I meant ("implementation" rather than "compiler"), but I was
> > thinking of languages that do not have interpreters (e.g. C), though in
> > theory interpreters are possible for any language.
>
> don't implement everything.)
>
> CINT, EiC, and ICI seem to be the most popular ones. I've used one
> in a job a few years back that was an extension language. It was nice
> because if the interpreted version wasn't fast enough, you could compile the
> extension and load it as a dll. (I don't recall the name, and it was hacked by
> the company to export our own bindings. The only non-compliance I had found was
> that adjacent string literals were not merged.)
I took a look at ch, from http://www.softintegration.com some time
ago. It is not bad, but unfortunately fails in the acid test of
compiling valid C99 (or 89) code, largely due to the excessive use
of new reserved words.
Marin David Condic
Ada or any other language was ever going to stop you from producing code
that had errors in it. The original idea was that languages exist (of which
Ada is one) that perform compile time and runtime checks that reduce or
eliminate whole classes of errors and that this is a good and desirable
thing. Evidence exists to indicate that stronger, more robust, more
reliable, more secure systems tend to get built if compilers check for
common, everyday programming errors and eliminate them. Nobody ever said you
can't build reliable software in languages that *don't* perform these sorts
of checks, but it isn't a stretch to claim that the level of effort is going
to be higher and the probability of success lower. Hence, the case is being
made that perhaps developers should consider safety and security concerns
when selecting a language for implementation. That hardly seems like some
wild-eyed claim that using Ada (or whatever language du jour you like) is
going to prevent programmers from building things that fail.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Beelsebob" <tat...@cs.york.ac.uk> wrote in message
news:65bd5935.01080...@posting.google.com...
Marin David Condic
language (or lock) is going to entirely prevent exploitable holes in systems
because holes result from logic errors as well as simple programming errors.
Hence, it is correct to conclude that if only Microsoft used Ada there would
still be the possibility of security breeches. But I'd still argue that
usage of a given language that includes stronger checks for errors
ultimately results in a stronger lock. The stronger the lock, the less
likelihood someone is going to break in - or at least you've reduced the
number of thieves you've got to worry about. The fact that somewhere there
exists one thief who can break any lock doesn't mean I should quit locking
my front door.
A more important question to toss out would be "What is the cost incurred
when someone *does* find a hole to exploit and *does* break in?" If you are
building an OS that is going to be used by web servers, that cost can be
pretty high. If the cost is high, one ought to consider investing in the
stronger lock rather than the dime-store-cheapie that can be got around with
a bobby pin. That's where Microsoft might have a big advantage by developing
an OS using Ada - it doesn't cover all the possible holes, but it sure is
going to cover some non-trivial number of them and that might save them and
their customers a lot of money by preventing some number of attacks. Call it
"Insurance".
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Chris Torek" <to...@BSDI.COM> wrote in message
news:9k9s85$s0o$1...@elf.eng.bsdi.com...
> In article <9k9nci$1cq$1...@nh.pace.co.uk>
>
> No, not at all. I agree that there are (more or less) objective
> measures that show that the defect rate in some languages (e.g.,
> Ada) is far lower than the defect rate in other languages (C,
> assembler, etc). I will even agree with one who argues that it
> would be harder to break into a system with 100 defects than one
> with 1000. But as far as actual breakins go:
>
> >There you will find additional evidence that language choice *does*
> >make a difference in terms of productivity and defects.
>
> Until you get the number of defects close to zero -- I am not sure
> "how close" is required; obviously zero suffices, given an appropriate
> definition of defects; but I think zero is also unachievable unless
> given an inappropriate definition :-) -- there will still be
> "exploitable bugs" in systems. My argument is that, if we somehow
> achieved this more perfect world, the crackers would simply change
> their tactics: instead of using easily-cracked buffer overflow
> bugs, they would use more-difficult (but available today) tricks
> like TCP session record and replay.
>
> The "real world" analogy of locks is useful here. Locks can keep
> "mostly-honest" people honest, and the better the locks, the greater
> this effect becomes. It is certainly foolish to say: "well, this
> cheap lock does not stop some thieves, therefore we should eliminate
> all locks" -- but it is equally foolish to say "aha, this more-expensive
> lock stopped that particular thief, therefore we should all just
> use this lock and decree perfection".
>
> In other words, I do not dispute that code written in Ada tends to
> be better; I just think it is a mistake to go from there to "if
> only Microsoft wrote in Ada, there would be no more Code-Reds."
Marin David Condic
of programmers needed to do the job gets much beyond "1" - and probably not
even then. Here's a simple fact of life: People are stupid from time to
time. Some more than others. Some more frequently than others. Some in a
continuous state of stupidity. When you have to hire 1000 programmers for
some job at hand, you can bet your life that the staff is not going to be
100% "A-Team" players. If you are counting on everyone being 100% at all
times in order to not produce stupid errors, then you're living in a fool's
paradise.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Larry Kilgallen" <Kilg...@eisner.decus.org.nospam> wrote in message
news:$Id63y...@eisner.encompasserve.org...
> At a 50,000 foot level, it is better to equip the troops with tools that
> have safety guards on them. They may remove the guards from time to time,
> but that is better than for a giant corporation to pretend it is capable
> of only hiring people who are so skilled that they would never need a
> safety guard.
Marin David Condic
not have saved anything anyway - it was a question of proper FDA.) in order
to gain needed performance. A static analysis was done that insured the code
was correct for the Arianne 4 flight envelope. It worked successfully in
that environment. Moving it to the Arianne 5 was done without any review of
those issues and nothing was done to test the unit in the new flight
envelope.
In other words, the software did *precisely* what it was designed to do - it
was just too bad that what it was designed to do wasn't the right thing to
do.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Ed Falis" <efa...@mediaone.net> wrote in message
news:3B694F80...@mediaone.net...
Marin David Condic
Ada. I won't swear to that because I can't cite specifics - but I can attest
to this: Aircraft jet engines have controls programmed in Ada and they work
quite well, thank you. (Take a bow, Marin!) BTW: This is more than just
military jet engines - large commercial jet engines also have Ada on board.
Why? Because if the engine control fails in an aircraft, a pilot (and maybe
passengers) are going to have a really bad day. They tend to not have a
sense of humor about it either. And they aren't going to buy the excuse that
"Any *competent* programmer..." wouldn't have let this happen.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Mike Smith" <smi...@michaelsmith.NOSPAMorg> wrote in message
news:tmhe597...@corp.supernews.com...
>
Dan Cross
Mike Smith <smi...@michaelsmith.NOSPAMorg> wrote:
>> Well, the same could be said of assembly language programming, but do
>> we program major software systems in assembler? And of course it's
>> tautological that only erroneous programs have bugs.
>
>Define "major". Is the software for automotive engine computers written in
>Ada? The embedded world is one of the most "major" categories of software
>development, and I'd bet that a lot of that is in fact written in assembly.
Actually, a significant amount of embedded systems development is done
in high-level languages (a fair amount is even done in Ada). Sure, a lot
of things use assembler at some point (even Unix has some assembler
routines in it), but it's usually not the focal point.
- Dan C.
Brian Rogoff
> Dale Stanbrough wrote:
> > Perhaps I should ask you this question...
> >
> > Would you be happy if the C language went back to not
> > enforcing/type checking parameters to functions?
>
> (there was a distinction made for floating point values). I can
> tell you, the only thing that was worse to debug, was assembly
> language! Everything (but floats) were a word (on the Honeywell,
> that was a 36-bit word). To work with strings you did procedure
> calls... what a nightmare to debug.
>
> When C came along, it was a blessing. Why? Stronger type checking
> and other "language safeguards".
>
> But today, C is the "B" of yesteryear. Ada is a big improvement
> over C, even C++ and yes, Java.
You know, I agree with you. Strong static type systems are a good thing.
I tried Ada 95 and did find it more productive than C or C++ when you
factor out the library advantages of C and C++. Still, I write C far more
than Ada and I don't see that changing for a while, unfortunately.
If you look at the newsgroups in the distribution list, you'll see that
this troll was crossposted to comp.lang.functional. Many people who read
that (this?) list probably wouldn't argue about your statement, but would
say "so what?". Couldn't you take the next step and say Ada is now like
B on account of more advanced languages like SML, Haskell, Mercury, and
OCaml? Or, would you argue that type inference has deleterious effects
on program readability and maintainability?
Anyways, I bet someone could take a trimmed down Ada, maybe the SPARK
subset, and make a pretty slick little pseudo functional language with a
sophisticated type system, along the lines of what the Cyclone project at
Cornell does with C.
-- Brian
Reivilo Snuved
Wasn't there, also, a program management decision NOT to perform a
(arguably long/costly) integrated test, which would have revealed the error ?
- it did indeed, when it was performed ... after the flight.
--
Olivier Devuns | Aonix: http://www.aonix.com
Dan Cross
Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
>Yes, and the seat belt actually nicely illustrates Kaz's point.
>
>Immediately after the seat belt was introduced, the number of fatalities
>in accidents plummeted.
>
>The years after, the number slowly rose again, because drivers adapted
>to the new safety level seat belts provided and were willing to take
>risks they wouldn't have taken without them.
Yes, but would the average car driver buy a car without seat belts now?
Assuming the answer is, ``no...'' why would the average programmer choose
to use a programming language with seat-belt like features?
>The nature of the fatalities have changed, yes. Nowadays, it's mostly
>innocent bystanders that get killed, not the driver that flies through
>the windscreen.
Very sad, but undoubtedly true. :-( I consider myself very lucky to
live in a place where I don't have to use a car to get anywhere (New
York City).
Going back to programming, can we guess that as the number of programming
related defects goes down, the number of design related defects rises? Or
is it that we're no longer hiding those design related defects behind our
programming errors?
- Dan C.
Daniel Fischer
> Going back to programming, can we guess that as the number of
> programming related defects goes down, the number of design related
> defects rises?
Yes. Proof of concept: Java. :)
> Or is it that we're no longer hiding those design related defects behind
> our programming errors?
Don't think so. The more possible programming related defects you need to
consider, the more you think about your design.
Daniel
--
IMO, anyway.
end message by (Daniel Fischer <d...@gueldenland.de>)
clc FAQ: http://www.eskimo.com/~scs/C-faq/top.html
08/02 Our Lady of Los Angeles in Costa Rica
Dan Cross
Daniel Fischer <d...@gueldenland.de> wrote:
>> Or is it that we're no longer hiding those design related defects behind
>> our programming errors?
>
>Don't think so. The more possible programming related defects you need to
>consider, the more you think about your design.
Hmm. But as the minutia that we have to deal with goes away as
programming becomes more abstract, we are freed to concentrate more on
the design. I'd have thought that worrying about the programming
related defects took up so much time there was little left to worry
about the design. Though on the other hand, one can see that if
something is really hard to implement, folks will think really hard
about how to make it easier (and hence less error prone).
Maybe the problem is that as our ability to deal with complexity goes
up, we feel compelled to build more complex systems ``because we
can.'' In other words, it's a two edged sword.
- Dan C.
Scott Ingram
My point exactly. Ada will do what you tell it to do: including
telling an Ariane 5 to fly like an Ariane 4, even though it can't
possibly do that. Though that does seem a higher level problem than
a buffer overflow, where you have to jump through some hoops to make
that happen.
--
Scott Ingram
Vice-Chair, Baltimore SIGAda
System Development and Operational Support Group
Johns Hopkins University Applied Physics Laboratory
David Gillon
Marin David Condic wrote:
> "Mike Smith" <smi...@michaelsmith.NOSPAMorg> wrote:
> > Define "major". Is the software for automotive engine computers written in
> > Ada? The embedded world is one of the most "major" categories of software
> > development, and I'd bet that a lot of that is in fact written in assembly.
>
> Ummmmm Actually, I've heard tell of automotive computers being programmed in
> Ada. I won't swear to that because I can't cite specifics - but I can attest
> to this: Aircraft jet engines have controls programmed in Ada and they work
> quite well, thank you. (Take a bow, Marin!)
It occurs to me I've never seen a comparison between the complexity of a
typical
automotive engine controller and a jet engine FADEC. Anyone have any
useful data for comparison--LoC, function points, whatever?
> BTW: This is more than just
> military jet engines - large commercial jet engines also have Ada on board.
Also latest generation large commercial jets in general, the Boeing 777
being a case in point.
> Why? Because if the engine control fails in an aircraft, a pilot (and maybe
> passengers) are going to have a really bad day. They tend to not have a
> sense of humor about it either. And they aren't going to buy the excuse that
> "Any *competent* programmer..." wouldn't have let this happen.
Ditto for the flight controls and other safety critical avionics.
FAA/JAA certification requirements might come as an unpleasant shock to
a lot of developers used to working at lower safety integrity levels.
--
David Gillon
CBFalconer
>
> Dale Stanbrough <da...@cs.rmit.edu.au> wrote:
>
> > Would you be happy if the C language went back to not
> > enforcing/type checking parameters to functions?
>
> at compile-time. Checking array bounds has an impact on the performance
> of the program itself.
> Oh, btw, there _are_ bounds-checking compilers for C. They get used
> where the extra safety is deemed important enough to justify the loss of
> speed.
elsethread (I think) I recently made a recommendation about type
definitions, which could impose strong type checking in C at the
cost of a single new reserved word (I suggested deftype, if you
want to do a google search on c.l.c). Such a feature would go far
to removing out-of-bounds errors by insisting that an array be
indexed by a declared index type. Everything would be done at
compile time. Without a specific cast (error prone) assignments
to the type would have to be of the type itself. If the type can
specify a subrange things would be even better, but that
immediately implies range-checking code, so is probably not C
compatible.
David Gillon
Goran Larsson wrote:
> The report clearly shows that you can have problematic software in
> any language.
Perhaps more appropriately, choice of software implementation language
cannot alleviate design failures at the systems level.
OTOH choice of implementation language may well affect rates of
implementation errors.
--
David Gillon
Marin David Condic
to
consider, the more you think about your design" then it stands to reason
that we all ought to go back to programming in machine code. After all, I
can't think of a better way of increasing the number of possible programming
defects than having to worry if the zero you just wrote should have been a
one. Machine code programming ought to result in bullet-proof, perfect
software design! :-)
I'm not against someone bench-checking their code for errors - maybe
re-reading it as you tidy up the format and re-thinking your assumptions -
or even just leaning back and thinking about the design and wondering if
there is a better way. I do that all the time. (Of course there comes a time
when you need to shoot the programmers and move along into production.) But
I just don't think it is reasonable to believe that adding automated checks
for errors can be anything *but* a good thing.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Dan Cross" <cr...@augusta.math.psu.edu> wrote in message
news:9kbvsr$a...@augusta.math.psu.edu...
Marin David Condic
writing programs in Ada guaranteed bug-free code?
And you've got it bass-ackwards - they took the range checks *out* because
their analysis indicated the values could *never* exceed valid ranges - so
long as you were in an Arianne 4 flight envelope. Without the range checks,
the math triggered a hardware overflow that the FDA decisions indicated
*must* be a sensor failure because it *couldn't* happen in an Arianne 4
flight envelope. Hence, shut down the channel and switch to the other side.
The software worked as it was designed to work - doing *exactly* what the
programmers wanted it to do - it just wasn't the right thing for Arianne 5.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Goran Larsson" <h...@invalid.invalid> wrote in message
news:GHGA3...@approve.se...
> In article <slrn9mi1q3.7kb...@kiuk0156.chembio.ntnu.no>,
> Preben Randhol <randho...@pvv.org> wrote:
>
> > Perhaps read it again.
>
> Why?
>
> The report clearly shows that you can have problematic software in
> any language. It was also ironic that it was a compiler generated
> range check on a value (that was not going to be used) that was the
> event that started the destructive chain of events. The management
> decision that any exception had to be due to hardware error (and
> warranted a shutdown) was _perhaps_ influenced by the belief that
> writing code in Ada resulted in bug free programs. :-)
Scott Ingram
>
> In article <slrn9mi1q3.7kb...@kiuk0156.chembio.ntnu.no>,
> Preben Randhol <randho...@pvv.org> wrote:
>
> > Perhaps read it again.
>
> Why?
>
> The report clearly shows that you can have problematic software in
> any language. It was also ironic that it was a compiler generated
> range check on a value (that was not going to be used) that was the
> event that started the destructive chain of events. The management
> decision that any exception had to be due to hardware error (and
> warranted a shutdown) was _perhaps_ influenced by the belief that
> writing code in Ada resulted in bug free programs. :-)
>
> --
> Göran Larsson Senior Systems Analyst hoh AT approve DOT se
I think Ed and Preben's point is that the code in question was
bug free...in the Ariane 4. I don't think any of us are naive
enough to believe that using language X or toolset Y will save
us from problematic software, but certain languages are better
at reducing certain kinds of errors. What the Ariane disaster
illustrates best is that even Ada can't overcome bad management
decisions.
Dan Cross
>The report clearly shows that you can have problematic software in
>any language. It was also ironic that it was a compiler generated
>range check on a value (that was not going to be used) that was the
>event that started the destructive chain of events. The management
>decision that any exception had to be due to hardware error (and
>warranted a shutdown) was _perhaps_ influenced by the belief that
>writing code in Ada resulted in bug free programs. :-)
I'm afraid that this is inaccurate (as has already been pointed out),
but it also misses the point. No one ever said you couldn't write bad
code in Ada, but we did point out that it's easier to write good code
in it.
A lot of the arguments I've read in this thread in defense of, eg, C,
are analogous to the argument, ``Well, my friend died in a car crash
even through s/he was wearing a seat-belt, so why should I bother
wearing mine?'' One hopes the answer is self-evident.
- Dan C.
Daniel Fischer
- followup ("Marin David Condic" <marin.condic...@pacemicro.com>)
> If it is true that "The more possible programming related defects you
> need to consider, the more you think about your design" then it stands
> to reason that we all ought to go back to programming in machine code.
Like back when we were allowed to run our punch cards through the
"computer" once a day, 5 days a week? Yes, I agree, that would help.
On the other hand it would take years[1] to write "Hello, World" ,)
Daniel
[1] Adequate Hyperbole.
Dan Cross
Marin David Condic <marin.condic...@pacemicro.com> wrote:
>If it is true that "The more possible programming related defects you need
>to
>consider, the more you think about your design" then it stands to reason
>that we all ought to go back to programming in machine code. After all, I
>can't think of a better way of increasing the number of possible programming
>defects than having to worry if the zero you just wrote should have been a
>one. Machine code programming ought to result in bullet-proof, perfect
>software design! :-)
Err, I think you're refering to Daniel Fischer here, not me. Watch the
attributions, please. :-)
I think there is a definite trend to treat more complex things with
more thought. But, I contend that part of addressing the complexity is
to use tools that eliminate some of it, including programming
language. Therefore, if programming in, say, Ada instead of C reduces
some of the complexity of the task, then that's a good thing.
>I'm not against someone bench-checking their code for errors - maybe
>re-reading it as you tidy up the format and re-thinking your assumptions -
>or even just leaning back and thinking about the design and wondering if
>there is a better way. I do that all the time. (Of course there comes a time
>when you need to shoot the programmers and move along into production.) But
>I just don't think it is reasonable to believe that adding automated checks
>for errors can be anything *but* a good thing.
Part of any software development process should be, IMHO, desk checking
code via formal reviews (and design, requirements, etc...). In general,
I think we need more rigor, not less, but we also need better tools so
that we can apply that rigor to the appropriate places (design sticks out
in my mind most clearly) instead of the dull minutae of programming.
- Dan C.
Larry Kilgallen
> Beelsebob wrote:
>>
>> [origional message]
>>
>> So your point is that you can use a buggy microsoft implementation of
>> C++ to write a virus.
>>
>> Now then let me see... oh yes, you can use Ada (not even a buggy
>> implementation of it) to cause the Arian 5 rocket to try and turn
>> round in mid flight, and disintegrate into many tinny little burrning
>> pieces.....
>
> My point exactly. Ada will do what you tell it to do: including
> telling an Ariane 5 to fly like an Ariane 4, even though it can't
> possibly do that.
That has the advantage that at least you can blame the failure on
management :-)
Larry Kilgallen
> In article <slrn9mi1q3.7kb...@kiuk0156.chembio.ntnu.no>,
> Preben Randhol <randho...@pvv.org> wrote:
>
>> Perhaps read it again.
>
> Why?
>
> any language. It was also ironic that it was a compiler generated
> range check on a value (that was not going to be used) that was the
> event that started the destructive chain of events. The management
> decision that any exception had to be due to hardware error (and
> warranted a shutdown) was _perhaps_ influenced by the belief that
> writing code in Ada resulted in bug free programs. :-)
Waking up to the fact that "Hey, I'm on the wrong rocket" certainly
seems a good reason to shut down. Is there any proof that the rest
of the program would have behaved correctly in the wrong rocket ?
Daniel Fischer
- followup ("Larry Kilgallen" <Kilg...@eisner.decus.org.nospam>)
> Waking up to the fact that "Hey, I'm on the wrong rocket" certainly
> seems a good reason to shut down. Is there any proof that the rest of
> the program would have behaved correctly in the wrong rocket ?
According to ESA, the failure was caused by a conversion of a value from a
64 bit floating point representation to a 16 bit integer representation.
There was no protection against an operand error in this place, while here
was in others.
The value was much higher than expected because the early part of the
trajectory of Ariane 5 differs from that of Ariane 4 and results in
considerably higher horizontal velocity values.
You can read the full report at
http://www.esa.int/htdocs/tidc/Press/Press96/ariane5rep.html
Daniel
Wes Groleau
> > Any language that attempts to be called serious bootstraps
> > itself. Needless to say that the first compiler of a new language wasn't
> > written in the language itself,
>
> Just a small nit - there's nothing to stop you writing the first
> compiler of a new language using an interpreter for that language. I
I believe the first version of GNAT was actually written in Ada
and compiled with an Ada 83 compiler.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
Darren New
> seems a good reason to shut down. Is there any proof that the rest
> of the program would have behaved correctly in the wrong rocket ?
Since it was *supposed* to have been shut down before the rocket even
left the pad on the A5, one would be led to assume yes.
followups redirected.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dn...@san.rr.com
Only a WIMP puts wallpaper on his desktop.