On Tue, 16 Apr 2002, Clive D.W. Feather wrote:
> Donn Terry said:
> > If you're asking for C to make data and function pointers commensurate
> > in any significant sense, forget it right now.
> > >>> Nope: just that it be possible to write a profile that does that.
> > (There may be
> > something in the standard that "blocks" the profile.)
>
> There's nothing in the Standard that (for example) forbids an
> implementation that makes *all* pointer types use the same representation.
> That would suffice to solve the dlsym problem.
Merely allowing function pointers to be converted to void * and
then back again would also solve the problem. In other words, the
common extension J.5.7 described in C99, which was inherited from C89.
There are likely deeper problems implementing dlopen() on a system where
code and data are that different, and any solution to those problems
will likely obviate the dlsym return value issue.
In any system that allows dynamic loading, it's not unreasonable to
expect code to be treatable as data and vice versa. If there is a
difference between the pointers, it's likely that data pointers that
will be wider (e.g. ``fat'' pointers for software bounds checking). In
that case, the wider void * pointer can accomodate any function pointer
value.
Lastly, every C language lawyer knows that calling a dlsym() function
invokes undefined behavior, unless that function is actually defined in
the C program itself. It's absurd to fret over the return value of an
ill-defined expression. :)
--
Meta-CVS: solid version control tool with directory structure versioning.
http://users.footprints.net/~kaz/mcvs.html http://freshmeat.net/projects/mcvs
|