🚀 go-pugleaf

In article <DFxJ75.3w0@research.att.com> ark@research.att.com (Andrew
Koenig) writes:

|> In article <5vE-N3F6nTB@site71.ping.at> wsog@site71.ping.at (Walter Sommergruber) writes:

|> > > A core dump in that context is neither better nor worse than any
|> > > other kind of run-time trap that prevents the program from yielding a
|> > > result. --

|> > Do you really think so ? What will your customers say about a program that
|> > crashes with a core dump ? I think most of them prefer a program where
|> > they get a message "Sorry, internal error. Contact ...." or (in the case
|> > the error is not severe) a program that makes another try.

|> Every system I've ever seen provides a way to do just that,
|> usually by calling signal() or something like it.

It occurs to me that the real problem without bounds checking isn't
when it core dumps.  As Andy points out, in many cases there are ways
of making the core dump no worse than a bounds check error.

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.

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.
-- 
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