Re: [lmi] product editor patch

[Vaclav Slavik]

Greg Chicares wrote:
> > Before moving on, I'd like to consider whether we might have
> > similar problems elsewhere, and whether we can turn this into
> > a link-time error so that we'll never meet it at run time again.
>
> Perhaps the best we can hope to achieve is an in-your-face
> runtime error that reliably occurs with HEAD, whether or not
> any customized files not in HEAD are used.
>
> I don't see how to make it a link-time error with ELF;
>   http://www.haible.de/bruno/woe32dll.html
> with PE, perhaps we could do that by introducing __declspec
> decorations; yet, as noted in 'workhorse.make':

I think we can achieve link errors on ELF platforms and runtime error 
that reliably happens at runtime immediately after loading the DLL on 
Windows, regardless of when or if warning() etc. is called.

With ELF, it's simple: just not include the callback pointers in 
liblmi and put them in the application instead. The library will then 
have some unresolved symbols in it, but that's fine -- they will be 
resolved from the program's executable at runtime. And the linker 
will complain when linking the program if you forget to include one 
of the objects that implement these symbols (or if you include more 
than one). (A corollary of this is that we don't need callback 
pointers at all when building for ELF.)

On Windows, we have to keep callback pointers in the DLL, but we can 
initialize them to point to values provided by the application when 
the DLL is loaded. To do this, we need to export callback symbols 
from app's  executable using __declspec(dllexport) (this is highly 
unusual, but possible). At runtime, DLL's DllMain would use 
GetModuleHandle(0) to find callback functions all set (DLL's) 
callback pointers. If it failed to resolve them, it would terminate 
the app.

What do you think about it, should I [try to] do it like this?

regards,
Vaclav


-- 
PGP key: 0x465264C9, available from http://pgp.mit.edu/