[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
