![]() |
|
Message-ID: <20130707152740.GY29800@brightrain.aerifal.cx> Date: Sun, 7 Jul 2013 11:27:40 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: New articles on ewontfix On Sun, Jul 07, 2013 at 02:20:15PM +0200, Szabolcs Nagy wrote: > * Rich Felker <dalias@...ifal.cx> [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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.