From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3562 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: New articles on ewontfix Date: Sun, 7 Jul 2013 14:20:15 +0200 Message-ID: <20130707122012.GC15323@port70.net> References: <20130704164845.GA14035@brightrain.aerifal.cx> <4F9B79E1CAB949A2B6315F4A2AB900FE@lightcubesolutions.com> <20130704175806.GQ29800@brightrain.aerifal.cx> <20130705155411.GR29800@brightrain.aerifal.cx> 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 1373199629 326 80.91.229.3 (7 Jul 2013 12:20:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jul 2013 12:20:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3566-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 07 14:20: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 1Uvnx6-0001R9-HW for gllmg-musl@plane.gmane.org; Sun, 07 Jul 2013 14:20:28 +0200 Original-Received: (qmail 22481 invoked by uid 550); 7 Jul 2013 12:20:26 -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 22473 invoked from network); 7 Jul 2013 12:20:26 -0000 Content-Disposition: inline In-Reply-To: <20130705155411.GR29800@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3562 Archived-At: * Rich Felker [2013-07-05 11:54:11 -0400]: > I'm still trying to determine how to work out a formal definition of > library-safe. My thought is that it would be based on the property of > being able to combine two programs with well-defined behavior, both > using the library code, into a single program where each original > program runs starting with its own initial thread, such that the > combined program does not invoke UB and the two sub-programs match > their behavior before being combined. However there are lots of ugly > issues that have to be considered. > > With that done, the interesting part would be covering common failures > of libraries to be library-safe. i'm not sure if you can derive all the interesting failures from a single definition this definition covers multi-thread issues i think library safety should also cover single thread issues (abort in lib, unbounded resource usage, trusting input sources unjustifiably, strong assumtions about the environment..) and source code level issues (abi, visibility, namespace pollution, clean headers..)