From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3250 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Mon, 29 Apr 2013 23:55:00 +0200 Message-ID: <20130429215500.GJ12689@port70.net> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130426005545.GA7923@Caracal> <20130429101620.GG12689@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 1367272515 32762 80.91.229.3 (29 Apr 2013 21:55:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 21:55:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3254-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 29 23:55:15 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 1UWw2T-0002St-Ax for gllmg-musl@plane.gmane.org; Mon, 29 Apr 2013 23:55:13 +0200 Original-Received: (qmail 25983 invoked by uid 550); 29 Apr 2013 21:55:12 -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 25975 invoked from network); 29 Apr 2013 21:55:12 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3250 Archived-At: * 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) returning an error code when some inconsistency is detected seems simple, but error semantics are usually not trivial: is it enough to retry, or retry with different parameters or treat the failure as fatal, should all the related states be cleaned if they might contain sensitive data or would the library do this for us, how to report the error on the ui etc without documentation the user should prepare for the worst and that can easily turn into a harder problem than implementing sha1 from scratch > Encrypting more than 2^(block size) / 2 of blocks is broken too. that's why cryptographers should choose the block size wisely so the user does not have to worry about it