On Thu, Oct 21, 2010 at 1:37 PM, Andrew Haley <aph@xxxxxxxxxx> wrote: > On 10/21/2010 05:23 PM, Jeffrey Walton wrote: >>> that there can only ever be one definition of a symbol in a program, >>> and UNIX has always merged multiple definitions to achieve this >> Does the rule include that gloabl object destructors are to run on >> every unload, or the last/final unload or last call to dlclose (when >> the shared object gets unmapped)? > > I suspect that Bad Things would happen. :-) > > As far as I know, they are run, and if you have two definitions > of some object with a destructor, then you violate the ODR rule, > and it's all your fault! When I look at the original source files, it is clear that there is one definition. I'm not sure what is getting lost in the translation, but the runtime link-loader 'multiplying definitions' which lead to a crash is not desired behavior. I would claim it is a bug. Since what happens in one module crashes another module, I would go out on a limb and claim this bug might have security implications. >> Many folks don't expect their objects will be pulled out from >> under them until the last unload. It seems like a reasonable >> expectation to me. > Sure, but you break the rules, you get to keep all the pieces. I think the problem here is that the rule is f**k'd up. I would argue that many folks probably know about the rule. But how many know about it because they got bit in the ass by it versus RTFM'ing the manual in their spare time? In essence, the rule creates "Shared (Global) Data Segments" in the Microsoft world. Those things are quite dangerous (because one process can cause another to crash) and code cannot pass a security related quality gates if present [1]. In the Microsoft world, if you want to take the bull by the horns, you have to go out of your way to get it - it is not default behavior [2]. (And I know M$ is not a stellar example of security). Making a bad choice (ie, 'the rule') and documenting it does not make it all OK. Its not reasonably expected behavior, and it might have security implications. Jeffrey Walton [1] Howard and LeBlac, Writing Secure Code, ISBN 0-7356-1722-8, p. 677-78 [2] How do I share data in my DLL with an application or with other DLLs?, http://msdn.microsoft.com/en-us/library/h90dkhs0%28VS.80%29.aspx
