With gcc, you can add bounds checking easily with extended inline assembler.
It only adds one assembly instruction, and very little overhead. The C macro Bound(),
defined below, make it very simple. Here is a demonstration:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
/* create a plain vanilla array for our test */
#define LENGTH 15
static char test_array [LENGTH];
/* store the lower and upper limits of your test array */
struct _bounds limits = { 0, UPPER_BOUND(test_array) };
void
bound_test (int index)
{ /* if the index is out of range, create a core dump */
Bound (index, limits);
test_array[index] = 'a';
}
/*
* We can invoke our test procedure bound_test() by entering
* an array index on the command line. If the index is out
* of range for the bound_test() procecure, the x86 "bound"
* instruction will trigger a core dump.
*/
int main(int argc, char *argv[])
{
if (argc > 1) {
bound_test (atoi(argv[1]));
}
return 0;
Yes, Ada is excellent advice. GNU GNAT is superb, and one of the best multi-threaded debuggers is
ACT-Europe's
GVD GNU Visual Debugger.
GVD, the GNU Visual Debugger, incorporates all the features of regular
debugger GUIs and is complemented with
data display and visualization
capabilities more powerful than those offered by DDD (the Data Display
Debugger). GVD provides the ability to debug
multi-process/multi-threaded
applications in the same debugging session.
I'm a shareholder in IBM and I want IBM to
maximize my profits. Let's fact facts: *BSD is
a minor family of operating systems when compared
to the real industry players. From my perspective as an IBM shareholder, any IBM effort to support one of the various *BSDs would be an unwise use of
limited resources.
The total market
for *BSD notebooks among all vendors is quite small. You can't blame IBM for good
business decisions. And since there are other
choices available, what's the squawk?
Speaking as an investor, I have bad feelings about *BSD (financial). It is pretty clear
that *BSD does not have the broad industry backing required to be successful. Some endeavors
seem to be eternally "spooked" or fated. *BSD is perhaps one of the better examples of this
phenomenon. There is jinx that has hovered over *BSD for years. I don't know that anyone can
explain why. *BSD problems are fairly complex. I don't think you can give a simple one sentence
explanation for *BSD's failure. It reminds me of the Amiga's failure. The Amiga was an example
of some good ideas that were perpetually jinxed. *BSD has the unfortunate legacy to share that
same one way boat ride down the river Styx. Darwin's problems will only hasten the process
Interesting thoughts, but a hard answer for BSD's difficulties requires further investigation. One
could make a career out of the whole study of industrial design failures. In some cases, such as that of the
Tacoma Narrows Bridge Disaster,
the causes are self-evident (in
retrospect, anyway). In other cases, such as the problems with BSD unix,
the reasons for failure are more subtle and require some digging. On
the one hand, BSD had the problem with copyright violations which led
to a lawsuit. But would a lawsuit be sufficient to permanently cripple
the whole BSD project?
Perhaps the closest analogy in terms of industrial failures is that
of the
Ford Edsel.
Touted as the "car of the future", the Edsel was an
unqualified flop. Yet, there wasn't anything really all that terrible
about the Edsel. For whatever reasons, the public roundly rejected
it. The same could be said about BSD unix. There isn't anything terribly
wrong with it, but it has been pretty much rejected by the IT industry
at large. Did the legal problems play a hand? Most definitely. But that
doesn't explain it all.
There is no easy way to assign "x's" and "o's" to a dilemma of this
sort. In the end, you might have to call it "bad luck". The public bases
its choices on mysterious reasons that are beyond even the best marketing
hype. Why was the public enamored with the hula hoop? Why are scooters
now the latest craze? Those with the answers aren't saying. For every
success, there are dozens of unheard of failures which have disappeared
into obscurity. Anyone remember "Hacky Sack"? I thought so.
Slashdot Mirror
character arrays. Here is a more general version:
#define UPPER_BOUND(X) ((sizeof(X)/sizeof(X[0]))-1)
With gcc, you can add bounds checking easily with extended inline assembler. It only adds one assembly instruction,
;
/* create a plain vanilla array for our test */
/* store the lower and upper limits of your test array */
/* if the index is out of range, create a core dump */
/*
and very little overhead. The C macro Bound(), defined below, make it very simple. Here is a demonstration:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
struct _bounds {
uint32_t lower;
uint32_t upper;
} __attribute__ ((aligned (4)))
#define Bound(X,Y) __asm__ ( "bound %0,%1\n\t" : : "r" (X), "m" (Y) )
#define UPPER_BOUND(X) (sizeof(X)-1)
#define LENGTH 15
static char test_array [LENGTH];
struct _bounds limits = { 0, UPPER_BOUND(test_array) };
void
bound_test (int index)
{
Bound (index, limits);
test_array[index] = 'a';
}
* We can invoke our test procedure bound_test() by entering
* an array index on the command line. If the index is out
* of range for the bound_test() procecure, the x86 "bound"
* instruction will trigger a core dump.
*/
int main(int argc, char *argv[])
{
if (argc > 1) {
bound_test (atoi(argv[1]));
}
return 0;
}
GVD, the GNU Visual Debugger, incorporates all the features of regular debugger GUIs and is complemented with data display and visualization capabilities more powerful than those offered by DDD (the Data Display Debugger). GVD provides the ability to debug multi-process/multi-threaded applications in the same debugging session.
Links for those interested in Ada and GVD:
I'm a shareholder in IBM and I want IBM to maximize my profits. Let's fact facts: *BSD is a minor family of operating systems when compared to the real industry players. From my perspective as an IBM shareholder, any IBM effort to support one of the various *BSDs would be an unwise use of limited resources. The total market for *BSD notebooks among all vendors is quite small. You can't blame IBM for good business decisions. And since there are other choices available, what's the squawk?
Interesting thoughts, but a hard answer for BSD's difficulties requires further investigation. One could make a career out of the whole study of industrial design failures. In some cases, such as that of the Tacoma Narrows Bridge Disaster, the causes are self-evident (in retrospect, anyway). In other cases, such as the problems with BSD unix, the reasons for failure are more subtle and require some digging. On the one hand, BSD had the problem with copyright violations which led to a lawsuit. But would a lawsuit be sufficient to permanently cripple the whole BSD project?
Perhaps the closest analogy in terms of industrial failures is that of the Ford Edsel. Touted as the "car of the future", the Edsel was an unqualified flop. Yet, there wasn't anything really all that terrible about the Edsel. For whatever reasons, the public roundly rejected it. The same could be said about BSD unix. There isn't anything terribly wrong with it, but it has been pretty much rejected by the IT industry at large. Did the legal problems play a hand? Most definitely. But that doesn't explain it all.
There is no easy way to assign "x's" and "o's" to a dilemma of this sort. In the end, you might have to call it "bad luck". The public bases its choices on mysterious reasons that are beyond even the best marketing hype. Why was the public enamored with the hula hoop? Why are scooters now the latest craze? Those with the answers aren't saying. For every success, there are dozens of unheard of failures which have disappeared into obscurity. Anyone remember "Hacky Sack"? I thought so.