🚀 go-pugleaf

In article <DG010o.LFK@research.att.com> ark@research.att.com (Andrew
Koenig) writes:

|> In article <KANZE.95Oct5121708@slsvgqt.lts.sel.alcatel.de> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

|> > The real problem is when it doesn't.  So you read beyond the end of
|> > the array.  In many cases, particularly those involving built-in
|> > types, this *won't* core dump.  On the other hand, it is highly
|> > unlikely that the value you read will give the correct results.

|> Things aren't quite so simple.

They never are, of course.

|> For example, I know a number of people who were involved in
|> developing the Unix system commands.  When they started using
|> machines that checked for attempts to read location 0, programs
|> that had been apparently working for years started crashing.
|> There had been stray pointer errors in lots of these programs
|> that turned out in practice to be harmless.

I remember when this happened at one of my customers (10 or 12 years
ago).  Basically, our earlier versions of Unix had put a '\0' at
address 0, so it looked like an empty string.  One of the programmers
who was caught out actually claimed that this was standard Unix, and
we didn't have the right to change it.

|> Of course, if the people working on these commands had access to a
|> checking implementation all along, I would certainly have advocated
|> that they use it.  But they didn't.

And I think that we both agree: if it ain't broke, don't fix it.  As
long as there was no other significant reason to work on these
programs, I think I'd just continue to compile them without bounds
checking, and forget it.

Of course, if I had infinite time and resources...

|> > In such cases, a core dump or a bounds check error might actually be
|> > preferable.  With bounds checking, the error is guaranteed.  Without,
|> > you might, and then again, you might not.  There's nothing quite like
|> > non-reproduceable behavior for programmer job security.

|> Indeed.

|> Again, I think implementations that check the rules at run time are
|> a Good Thing, especialy if you can afford them.  But sometimes you can't.

I think that the real problem is that 99% of the time, we can afford
them, but 99% of the programmers think that they are in the other 1%.

I think that you pointed out the way the market affects compilers in
another posting.  I agree.  What it comes down to is this: if we
educate the programmers, the compilers will follow.  Whereas if the
compiler takes the lead, the only thing that will happen is that the
vendor will go bankrupt.

I can't say that I am particularly fond of the situation, but that's
the way it is.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung