M
Merrill & Michele
Elliott Back said:
#define elliot beck
_penry
/*your skills were not un-noticed*/
#define elliot beck
_penry
/*your skills were not un-noticed*/
W
wijhierbeneden
Elliott Back said:
A language HAS vulnerabilities. Ok the vulnerabilities could be caused
by the programmer (race conditions, off-by-one). But in Ada you can't
have numeric under- and overflow/ unsigned-signed mismatch/
bufferoveflow/format string bugs... In Java you don't have a unsigned
type/ bufferoverflow/heapoverflow/... . So C/C++ is vulnerable for
such faults. All I want to know is that there are even more of those
problems in C/C++. You can call it a vulnerabilities of C/C++ or not
it is a vulnerability that reside in programs written in those
languages.
F
Flash Gordon
On 26 Oct 2004 00:59:27 -0700
So what happens if you add 1 to an integer that is at it's maximum
value? It is still an overflow (in the normal sense of the word) even if
the language defines what happens. The programmer still has to make an
effort to handle it, whether that means catching the exception and
handling it gracefully or (as in C with unsigned types) detecting the
wrap around.
You don't have heap overflow in C. If malloc/realloc/calloc cannot
obtain enough memory then they fail and return a null pointer and the
heap is still intact.
Java can run out of memory on creating an object (say, another node on a
linked list) which is on the Java equivalent of a heap.
In saying Java doesn't have buffer overflows, I assume you mean it
is required to generate an exception on access beyond the end of an
array.
There are more ways for a programmer to shoot him/herself in the foot
with C or C++ than with Java and probably ADA, but neither Java nor ADA
are automatically safe, they both still require that the programmer
deals with issues such as resource exhaustion and what happens when you
increment an integer beyond its maximum value (whatever Ada and Java do
may not give the result you want without further work).
So what happens if you add 1 to an integer that is at it's maximum
value? It is still an overflow (in the normal sense of the word) even if
the language defines what happens. The programmer still has to make an
effort to handle it, whether that means catching the exception and
handling it gracefully or (as in C with unsigned types) detecting the
wrap around.
You don't have heap overflow in C. If malloc/realloc/calloc cannot
obtain enough memory then they fail and return a null pointer and the
heap is still intact.
Java can run out of memory on creating an object (say, another node on a
linked list) which is on the Java equivalent of a heap.
In saying Java doesn't have buffer overflows, I assume you mean it
is required to generate an exception on access beyond the end of an
array.
There are more ways for a programmer to shoot him/herself in the foot
with C or C++ than with Java and probably ADA, but neither Java nor ADA
are automatically safe, they both still require that the programmer
deals with issues such as resource exhaustion and what happens when you
increment an integer beyond its maximum value (whatever Ada and Java do
may not give the result you want without further work).
D
Dan Pop
In said:
Was the code that destroyed an ARIANE V rocket written in C or Ada?
Dan
M
Martin Ambuhl
Dan said:
Irrelevant. The culprit was "code reuse." Code used for the Ariane IV
which kept a pre-launch alignment process running after lift-off beyond
its normal time-limit was not removed for the Ariane V. The Ariane V
not only had no need for this code, but could not tolerate its activation.
D
Dan Pop
In said:
It is perfectly relevant to the point it was supposed to make: intrinsic
language safety counts for very little in the safety of the final program.
Too bad you missed it.
Dan
M
Martin Ambuhl
Dan said:
Sorry, I missed the part where you actually wrote anything more than
"Was the code that destroyed an ARIANE V rocket written in C or Ada?"
That question contains nothing which I could have missed.
D
Dan Pop
In said:
You were supposed to be able to figure out the rest by yourself. Too bad
you weren't.
Dan
M
Martin Ambuhl
Dan said:
I don't know what is bothering you. Making pointless snide remarks is
beneath you. Try kicking a cat; maybe that will help you.
D
Dan Pop
In said:
Not unless I could find the cat responsible for your obtuseness.
Dan
D
Dave Thompson
On Fri, 22 Oct 2004 20:16:40 +0200, jacob navia
where C++ fixes to a minor extent some of the problems from C.
Biggest is that functions must be declared and in prototype syntax,
which eliminates some of the opportunities for mismatching calls.
Further, though it isn't inherent in the language or officially
required, all practical C++ implementations to support overloading use
"typesafe" linking which catches some -- not all -- mismatched
function declarations, while C implementations (except yours) don't
need to and usually don't.
The implicit conversion from void* to any (possibly wrong) object
pointer is gone, although you still can do the (explicit) cast with
equally bad results. enums are distinct types and don't implicitly
convert from other enums (that were intended to be distinct), or from
integers although IME that is less often a problem.
A few string functions like strchr are overloaded to be const-safe,
and string literal values are officially const -- although they still
deprecatedly convert to a nonconst pointer (yuck!).
And C++ provides _alternatives_ to some of the things that are often
problems in C: std::string, vector and valarray, *streams with << >>,
new/delete (though delete[] is still a landmine), smart pointers that
can force initialization and do reference counting and/or GC. But
you're right that nearly all the things that are commonly problems in
C are still possible in C++.
- David.Thompson1 at worldnet.att.net
Given this corrected claim (not "all") there are still a few cases
where C++ fixes to a minor extent some of the problems from C.
Biggest is that functions must be declared and in prototype syntax,
which eliminates some of the opportunities for mismatching calls.
Further, though it isn't inherent in the language or officially
required, all practical C++ implementations to support overloading use
"typesafe" linking which catches some -- not all -- mismatched
function declarations, while C implementations (except yours) don't
need to and usually don't.
The implicit conversion from void* to any (possibly wrong) object
pointer is gone, although you still can do the (explicit) cast with
equally bad results. enums are distinct types and don't implicitly
convert from other enums (that were intended to be distinct), or from
integers although IME that is less often a problem.
A few string functions like strchr are overloaded to be const-safe,
and string literal values are officially const -- although they still
deprecatedly convert to a nonconst pointer (yuck!).
And C++ provides _alternatives_ to some of the things that are often
problems in C: std::string, vector and valarray, *streams with << >>,
new/delete (though delete[] is still a landmine), smart pointers that
can force initialization and do reference counting and/or GC. But
you're right that nearly all the things that are commonly problems in
C are still possible in C++.
- David.Thompson1 at worldnet.att.net
D
Dave Thompson
AIRandUI it wasn't the activation(? really continued running) as such,
although it wasn't *needed* at all after liftoff on 5 as it had for
some minutes on 4. It was the continued running while 5 accelerated
faster than 4, reaching a velocity or displacement (I don't recall
which) outside limits specified for 4 causing a kind of overflow trap
in _one_ (nav) computer, the "display" of which was then
misinterpreted by a different (control) computer, causing it to go out
of control -- it wrongly thought it was off course and commanded the
engines too far over trying to correct this nonexistent error.
So yes the problem was reuse, both for functionality not actually
needed or appropriate, _and_ outside the limits originally specified,
_plus_ incorrect (undesigned) interaction with a different system.
- David.Thompson1 at worldnet.att.net
P
Peter Pichler
Malcolm said:
ITYM very easy
