From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3563 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: New articles on ewontfix Date: Sun, 7 Jul 2013 11:27:40 -0400 Message-ID: <20130707152740.GY29800@brightrain.aerifal.cx> References: <20130704164845.GA14035@brightrain.aerifal.cx> <4F9B79E1CAB949A2B6315F4A2AB900FE@lightcubesolutions.com> <20130704175806.GQ29800@brightrain.aerifal.cx> <20130705155411.GR29800@brightrain.aerifal.cx> <20130707122012.GC15323@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 1373210879 2763 80.91.229.3 (7 Jul 2013 15:27:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jul 2013 15:27:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3567-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 07 17:27:55 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 1UvqsU-0002ro-O9 for gllmg-musl@plane.gmane.org; Sun, 07 Jul 2013 17:27:54 +0200 Original-Received: (qmail 30278 invoked by uid 550); 7 Jul 2013 15:27:54 -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 30270 invoked from network); 7 Jul 2013 15:27:53 -0000 Content-Disposition: inline In-Reply-To: <20130707122012.GC15323@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3563 Archived-At: On Sun, Jul 07, 2013 at 02:20:15PM +0200, Szabolcs Nagy wrote: > * 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 It attempts to. Having the "test" be with threads automatically covers all cases of using the library separately from multiple modules. > (abort in lib, This is covered. Just have program A cause the library to abort, and program B run successfully. Then the combined program wrongly aborts part B, and thus it's non-library-safe. > unbounded resource usage, I don't see how this can be quantified correctly, but in some sense, it is by the proposed definition. If part A consumes so many resources that part B can't run, that would be a failure of the test. However I'm reluctant to call that a failure since it could make any library fail. This is why the definition is difficult to get right. > trusting input sources > unjustifiably, I think that's more an issue of security, but the proposed definition precludes UB anyway. > strong assumtions about the environment..) Could you elaborate? > and source code level issues > (abi, visibility, namespace pollution, clean headers..) Yes, those are possibly issues that should be covered. Rich