Matt Seitz wrote:
> > Let me repeat what I think is the easiest way out of this: just change
> > the return of dlsym() to an implementation-defined typedef called, for
> > instance, dlsym_t.
>
> Rather than all these contortions to try and work around the C Standard,
I don't think it is much of a contortion, especially compared to how the
current definition of dlsym() implies the requirement that your C
compiler must support an extension that allows void pointers to be
converted to function pointers in a meaningful way.
The change I propose replaces that requirement with a much less
restrictive requirement that your compiler must be capable of supporting
*a type* that can be converted to and from data and function pointers
for the purpose of dlsym(). This lets you use compilers that don't
allow void* to be that type -- you just need to find a compiler that has
an integer type large enough to hold all pointers, and defines
conversions between that type and all pointers to preserve pointer
values. Given that C99 requires compilers to support a 64-bit integer
type or larger, this shouldn't be a huge issue on most realistic
hardware. And using an integer type allows you to rely on
implementation-defined behaviour rather than on an extension that
defines what normally is undefined behaviour.
In short, using implementation-defined typedefs is a good thing --
that's why we have things like "time_t" and "pid_t". You shouldn't see
it as a contortion.
> wouldn't it be easier to just:
Depends on what you mean by "easier". What I'm talking about involves
changing several sentences in the descriptions of dlsym() and <dlfcn.h>
and adding a typedef to implementations of the header. No real changes
in any other code (except on platforms that aren't capable of
implementing today's dlsym() anyway). Sounds pretty easy to me,
compared to adding a new function and changing the behaviour of the old
one.
> -Add a dlsym_f function that returns a pointer to function for function
>symbols
> -Keep dlsym with a void * for data symbols
> -Allow as an optional extension that dlsym can also be used for function
> symbols on those platforms that allow converting from void * to pointer to
> function.
Instead of calling it an extension, I'd rather say that it's
implementation-defined whether it returns NULL or a pointer that can be
converted to function pointer. This wording would let you avoid calling
it undefined behaviour on implementations that can't support the
extension.
> This would allow backward compatability on existing code, while providing a
> more portable option for new code.
I'm all for a more portable option for new code, but I think the idea of
*two* new functions is nicer. It allows the dlsym_data() variant to
return NULL if you give it the name of a function.
|