Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 7 Jul 2013 11:27:40 -0400
From: Rich Felker <>
Subject: Re: New articles on ewontfix

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.


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.