From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3255 Path: news.gmane.org!not-for-mail From: Gregor Pintar Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Tue, 30 Apr 2013 08:32:26 +0200 Message-ID: References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130426005545.GA7923@Caracal> <20130429101620.GG12689@port70.net> <20130429215500.GJ12689@port70.net> <20130430021014.GC20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1367303559 12286 80.91.229.3 (30 Apr 2013 06:32:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 06:32:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3259-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 30 08:32:39 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 1UX47D-0004N4-BS for gllmg-musl@plane.gmane.org; Tue, 30 Apr 2013 08:32:39 +0200 Original-Received: (qmail 28147 invoked by uid 550); 30 Apr 2013 06:32:38 -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 28139 invoked from network); 30 Apr 2013 06:32:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=79EvDRODOJ2hzSzfNjsXyOKz//dgXMSA2EYTAH2tfk4=; b=oDJhg3pqbH0btUUhsnIF3qGR0xkVedYSFauh7ou5IhLuegai7RSt3F1qL9Hz8oW7QV 1l901CkmygloY35L+IuDZE6l5HKZRe6Qfu1rE/xrJbT9Yey0Z4sjnxYeEKXcCTrjkSuO TlD124YhB2wDbGoGxVDBCZKwIMPZfThiSMSgxnHaIntFy2ZxkJQ2FqPOHa7rG18Yzkfo IkLZ5037TVO0VN9vQwNzZAnKhYs/0b8JfM91OQ6npI6A8KABZla2N5DCPrcjTWjBjcK2 CN+/uhLNa7xvjWyF7JuEgUyM1ewmbWrDPdQRNJMuCdNPyRMAFgEoiyBd1WwYmny20OLf vnnw== X-Received: by 10.180.183.50 with SMTP id ej18mr22100629wic.4.1367303547239; Mon, 29 Apr 2013 23:32:27 -0700 (PDT) In-Reply-To: <20130430021014.GC20323@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:3255 Archived-At: 2013/4/30, Rich Felker : > 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. > My idea was that program would be correct, if it inputs too much data to hash function. It is very cheap to implement in most algorithms (detect counter overflow). Otherwise program has to count it himself. However, in most cases it is too late to handle correctly when it already fails. Not returning error on too much input or output could silently cause incorrect usage. Using assert might be better idea since at that point it is fatal anyway, but that would cause data leak, unless program would catch SIGABRT (it should others like SIGINT anyway) and wipe data, but that requires all sensitive data in program is global.