e9a68cfbc3
"symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet). |
||
|---|---|---|
| .. | ||
| .cvsignore | ||
| dso.h | ||
| dso_dl.c | ||
| dso_dlfcn.c | ||
| dso_err.c | ||
| dso_lib.c | ||
| dso_null.c | ||
| dso_openssl.c | ||
| dso_win32.c | ||
| Makefile.ssl | ||
| README | ||
TODO ---- Find a way where name-translation can be done in a way that is sensitive to particular methods (ie. generic code could still do different path/filename substitutions on win32 to what it does on *nix) but doesn't assume some canonical form. Already one case exists where the "blah -> (libblah.so,blah.dll)" mapping doesn't suffice. I suspect a callback with an enumerated (or string?) parameter could be the way to go here ... DSO_ctrl the callback into place and it can be invoked to handle name translation with some clue to the calling code as to what kind of system it is. NOTES ----- I've checked out HPUX (well, version 11 at least) and shl_t is a pointer type so it's safe to use in the way it has been in dso_dl.c. On the other hand, HPUX11 support dlfcn too and according to their man page, prefer developers to move to that. I'll leave Richard's changes there as I guess dso_dl is needed for HPUX10.20.