From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3253 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Mon, 29 Apr 2013 22:10:15 -0400 Message-ID: <20130430021014.GC20323@brightrain.aerifal.cx> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130426005545.GA7923@Caracal> <20130429101620.GG12689@port70.net> <20130429215500.GJ12689@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367287832 7852 80.91.229.3 (30 Apr 2013 02:10:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 02:10:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3257-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 30 04:10:31 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UX01U-00066B-RQ for gllmg-musl@plane.gmane.org; Tue, 30 Apr 2013 04:10:29 +0200 Original-Received: (qmail 32236 invoked by uid 550); 30 Apr 2013 02:10:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32226 invoked from network); 30 Apr 2013 02:10:27 -0000 Content-Disposition: inline In-Reply-To: <20130429215500.GJ12689@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3253 Archived-At: 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. Rich