Re: Another way to salvage Annex K and its constraint handler

[Rich Felker <dalias at libc dot org>]

On Thu, Dec 17, 2015 at 11:05:00AM +0100, Florian Weimer wrote:
> On 11/20/2015 10:35 PM, Rich Felker wrote:
> > On Fri, Nov 20, 2015 at 09:45:04PM +0100, Florian Weimer wrote:
> >> On 11/20/2015 08:35 PM, Rich Felker wrote:
> >>
> >>> dlopen is outside the scope, but the behavior of a conforming program
> >>> that just happens to be dynamic-linked rather than static-linked is
> >>> not outside the scope. You cannot just ignore the constraint handler
> >>> set by one function because it happened to be performed from code in a
> >>> different DSO. What DSO the code lies in is an implementation detail.
> >>> And of course such a "solution" does nothing for static linking
> >>> anyway.
> >>
> >> I'm not sure if I agree, at least as far as C is concerned.  Windows has
> >> much more DLL-local state than we do, and that's not a reason why it's
> >> non-complaint.  With a functioning dlmopen, we get much more of such
> >> state, if we like it or not.
> > 
> > At least with the MS tools, Windows DLLs do not provide semantics
> > equivalent to linking their object files directly into the main
> > program. On the other hand, all Unix-like systems I'm aware of, and in
> > particular the ELF binary format, have gone to great lengths to make
> > it so that, in the absence of explicit use of extensions, a
> > dynamically linked conforming program behaves exactly the same way it
> > would if all its translation units were put together in the abstract
> > machine specified by the C standard.
> 
> It's still surprising how many APIs (libresolv, get*ent) were designed
> so that they work with per-DSO heaps.  Was this just due to performance
> considerations?

I don't get what you mean by "per-DSO heaps". They're just working
with global data.

> Back in the pre-ELF days, shared libraries were a
> rather involved affair, so whether there was an exact equivalence is a
> bit muddy.

Pre-ELF, this stuff was all broken. The big accomplishment/appeal of
ELF was fixing the semantics of dynamic linking so that applications
and libraries would not have to be aware of the (previously
non-conforming) implementation details of the dynamic linking system.

> Anyway, I brought this up because I do think that for the Annex K
> constraint handler, the per-DSO model is much more useful to programmers
> than the per-thread model.  With the per-DSO model, you don't usually
> have to care about constraint handlers in a library at all.  With the
> per-thread model, you have to set and restore the constraint handler
> around any use of Annex K functionality, which pretty much kills the
> entire thing due to inconvenience.

You absolutely do have to care unless you require dynamic linking,
which is not a reasonable behavior for library code. With static
linking there is only one "DSO" so "per-DSO model" is useless.

Rich