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.