[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130430021014.GC20323@brightrain.aerifal.cx>
Date: Mon, 29 Apr 2013 22:10:15 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On Mon, Apr 29, 2013 at 11:55:00PM +0200, Szabolcs Nagy wrote:
> * Gregor Pintar <grpintar@...il.com> [2013-04-29 19:35:03 +0200]:
> > > (eg hash_update(ctx, buf, len) should never fail
> > > even if there is a counter in ctx that can overflow
> > > every 2^64th bit of input, documenting the behaviour
> > > for longer inputs is better, it would be even better
> > > if the apropriate standards were more careful about
> > > failures)
> > Devs that ignore return values would probably ignore documentation too.
>
> i think the problem is not ignorance, but the combinatorial
> explosion of code paths which increases bug probability
>
> in my view the purpose of error codes is to indicate runtime
> errors (eg allocation or io failures) and not to prevent bugs
> in the program logic (there are other tools for that, most
> notably the type checker, adding extra error handling paths
> for bug prevention usually makes things worse)
Agreed. You've expressed the issue very concisely and effectively. The
way I tend to think of it is that error codes should express a
condition that can occur in a correct program. If the condition can't
occur in a correct program, no effort should be spent at runtime
detecting it. If a program is going to go about detecting error codes
that couldn't occur without a bug in the program, though, it should do
so via assert() rather than complex error-propagation logic.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
