Re: New articles on ewontfix

[Rich Felker <dalias@aerifal.cx>]

On Sun, Jul 07, 2013 at 07:12:03PM +0200, Szabolcs Nagy wrote:
> > It attempts to. Having the "test" be with threads automatically covers
> > all cases of using the library separately from multiple modules.
> > 
> 
> ah ok
> 
> but then "program with well-defined behavior" is hard
> to specify

:)

> (i thought you assume working programs and only require
> that their combination does not break)

The idea is that a program is non-library-safe if there exists a pair
of programs, subject to certain conditions on the programs that remain
difficult to specify exactly, that do not individually invoke UB but
which invoke UB or whose outputs change for some interleaving.

> if well-defined can be any program that the language and
> the library documentation allows in a single-threaded
> execution then the program itself may invoke ub in
> multi-threaded case

Definitely not any program. For instance the programs must be
restricted not to define symbols that conflict with one another, or to
access the filesystem in ways that could conflict with one another,
etc. They should probably have no input at all. The difficulty is
putting these restrictions in place in such a way that we don't
gratuitously exclude libraries that have legitimate needs to access
the filesystem or network and which do so in safe ways.

> and a library interface can require a callback that
> does impossible things so no program is well-defined

I'm not sure what you mean.

> > > 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.
> 
> if the library documents its resource usage then it can pass
> the strong test
> 
> (and there are per-thread resources: stack)

Yes, the threads for A and B would be assumed to start with the same
amount of stack space they would have if they were the main thread.

> we also want that low resources or runtime failures are
> handled and don't cause ub: so the runtime environment
> should be part of the definition in some way
> 
> by unbounded resources i originally meant resource leaks,
> but "resource safety" seems to be hard to specify in general

Yes, and in some sense I think it's a separate issue.

> > > strong assumtions about the environment..)
> > 
> > Could you elaborate?
> 
> by environment i meant the system surrounding the program
> 
> and strong assumption is anything that is not guaranteed
> 
> eg if a library tries to connect to some webserver to
> get some information that is present locally as well,
> then it assumes internet connection unjustifiably

Yes, these are the most difficult since the behavior of the program is
really not self-contained. I think any formal treatment would have to
assume the network has been dummied-out and replaced with a fixed set
of responses to everything the program sends.

Rich