Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Apr 2013 22:10:15 -0400
From: Rich Felker <>
Subject: Re: High-priority library replacements?

On Mon, Apr 29, 2013 at 11:55:00PM +0200, Szabolcs Nagy wrote:
> * Gregor Pintar <> [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.


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.