Bounds checked arrays

[Nick Landsberg]

[snip]


You are undoubtably right that many people will jump to incorrect
conclusions. Probably some stupider managers will misunderstand it.
However, if your managers jump on a minor programming language
development as a reason to change the development process then they
are idiots. And if that is the case you have bigger fish to fry.

And you are absolutely correct, we have bigger fish to fry.

 

[Keith Thompson]

People who have already done explicit bounds checking on their data the
moment they get it from the outside, and know that all data that's
passed the tests can be trusted.

And who never make mistakes.

 

[CBFalconer]

AS/400?

Can you provide a pointer to your proposal? I'd be interested in
seeing it.

I have just thrown such ideas out upon the fallow ground of
usenet. Nothing complete or thought out exists that originated
with me.

Indexing into a description array saves space in each pointer, but
since each pointer dereference has to refer to the bounds information,
putting it in the pointer itself might make for faster execution.

The pointer has to hold an offset. For an array the bounds info
specifies the ends of that array, and its space (which stack
frame, which mallocation, etc). But a walking pointer, as used in
"while (*d++ = *s++);" has the same bounds, with the offset being
diddled.

[...]

Whereever you look, the C practice of brandishing pointers
indiscriminately poses apparently insoluble barriers to the
creation of accurate self-checking code.

My conclusion is that the language should be used in its original
mode - as structured assembly - and that critical code should be
written in better suited languages that have been designed for the
task.

It might be an interesting exercise to design a new language (as close
to C as possible, but no closer) that incorporates this kind of bounds
checking. If it can't be done without breaking existing code, then
there's little chance of the new language being called C, but there
seems to be a market advantage in designing new languages with C-like
syntax, even if they're incompatible (see Java and Perl, for example).
If a lot of existing C code can be ported to the new language without
too much effort, it might even catch on. It would probably need to
have a mechanism for working with C-style skinny pointers so it could
interface to existing C code (OS interfaces, for example); such a
mechanism should be very explicit so programmers aren't tempted to use
it by default (perhaps a type qualifier called "dangerous").

Why bother? Accurate languages already exist, including Ada and
Pascal. Since Ada is specifically intended to call routines in
other languages (e.g. C) there is no reason to try to defeat its
restrictions. To my mind the trouble with C++ and Java is that
they are so closely tied to C phraseology.

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:
[...]

Sorry, but C isn't the language for people needing bound checking.
Unfortunately, far too many such people do program in C... And even if
bound checking is eventually introduced, most of those people would
be the last ones to enable it in their code ;-)

I'm curious: which people *don't" need bounds checking?

Those who know what they're doing.

Dan

 

[Dan Pop]

Just because it is impossible to make bounds checking bulletproof
doesn't mean it is not a good idea. I think most of us who write C
would be thankful for it if it. I would be even if it only catches a
few mistakes during coding.

You either do something or you don't. Halfway solutions are simply not
good enough. You'd get a false sense of safety that's much worse than
knowing that you're fully on your own and have to rely on your own
checking.

AFAIK, there is a version of gcc with bound checking support. It doesn't
seem to be particularly popular even among gcc users.

And I have seen a beginner confused by a C compiler with bound checking
support. His code was correct, but the bound checker didn't realise it,
for one of the reasons I explained in my previous post.

Dan

 

[CBFalconer]

People who have already done explicit bounds checking on their
data the moment they get it from the outside, and know that all
data that's passed the tests can be trusted.

Unfortunately the design of C (and of any language without
subranges) is such that such pre-testing cannot be described to
the remainder of the program. This is one more reason that
checking, besides being impossible to fully implement, must also
be highly inefficient in C.

This whole discussion reminds me of wives trying to remake
husbands, or vice-versa. Let's just accept the language for what
it is, and possibly try to ameliorate a few rough spots.

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:
[...]
Sorry, but C isn't the language for people needing bound checking.
Unfortunately, far too many such people do program in C... And even if
bound checking is eventually introduced, most of those people would
be the last ones to enable it in their code ;-)

I'm curious: which people *don't" need bounds checking?

People who have already done explicit bounds checking on their data the
moment they get it from the outside, and know that all data that's
passed the tests can be trusted.

And who never make mistakes.

Or who take additional trouble to avoid certain classes of mistakes.

Dan

 

[Rob Thorpe]

You either do something or you don't. Halfway solutions are simply not
good enough. You'd get a false sense of safety that's much worse than
knowing that you're fully on your own and have to rely on your own
checking.

No, I don't agree. Halfway solutions are useful in engineering. In
many ways the C type system is rather halfway solution in the first
place, since you can break through it.

Read the paper I referred to further down this thread. In this case
the partialness of the solution is probably a lot less partial than
you imagine, it doesn't work if you link to libraries that don't use
it or you if you write your own memory allocation code. For instance
this horrible thing:

char *p = (char *)&bar + offsetof(struct foo, a) + 5;

would be handled sanely.

AFAIK, there is a version of gcc with bound checking support. It doesn't
seem to be particularly popular even among gcc users.

I would use it, but unfortunately it wasn't updated for modern GCC's,
the last version that had patches available was some egcs version.

And I have seen a beginner confused by a C compiler with bound checking
support. His code was correct, but the bound checker didn't realise it,
for one of the reasons I explained in my previous post.

I think that is a worthwhile price to pay for the benefits of bounds
checking.

 

[James Rogers]

Those who know what they're doing.

And those who never need to use code developed by somebody else.

You may know what you are doing but the person who developed the
library you are using may not be as good as you, or may have
applied different assumptions about the code and data than you
have. As mentioned elsethread, C offers precious little assitance
to the effort of making your assumptions visible to other parts
of a program. This is particularly true when dealing with issues
of separate compilation.

Jim Rogers

 

[Dan Pop]

(e-mail address removed) (Dan Pop) wrote in

And those who never need to use code developed by somebody else.

I am not responsible for bugs in code I haven't developed myself. And
since any program written for a hosted implementation has to rely on
external code, your point is moot.

BTW, if the bound checker was developed by someone else, how do you know
whether you can rely on it? Maybe your code was actually correct, but
there are buffer overruns in the bound checking code itself...

Dan

 

[Dave Thompson]

Bound checking is well defined on most languages which either don't
support pointers at all (Fortran <= F77) or have a very restricted notion
of pointers (Fortran >= F90 and Pascal).

Although many, probably most, F77 *implementations* do as extensions,
and I believe at least some Pascal implementations relax the language
restrictions. Raising exactly the same problems, of course.

PL/I has unrestricted pointers, and Ada has both (restricted and un),
which can't be checked except for special cases; but they (both) have
first-class arrays, at least w.r.t. passing as arguments, which thus
*can* be and are checked, unlike C.

In the no-pointers-at-all category you could add APL, BASIC, and LISP.
And if you can suppress your gag reflex long enough, COBOL.

(other problems snipped)

Sorry, but C isn't the language for people needing bound checking.
Unfortunately, far too many such people do program in C... And even if
bound checking is eventually introduced, most of those people would
be the last ones to enable it in their code ;-)

(Sadly) Agree. Unless it were mandatory. Even if it was the default,
many people who need it would go to the trouble of *disabling* it.


- David.Thompson1 at worldnet.att.net