I'm not particularly disagreeing with anybody, but a couple of points:
1) The size of either type of pointer could be the larger. On a
segment/offset machine,
function pointers might have to be, say, 48 bits for a 16 bit segment
and a 32 bit offset,
but for data pointers a segment can be assumed and they need only be
32 bits. On the other
hand, "fat pointers" might be useful for data but not functions.
2) Even if pointers are the same size, again on a segment/offset
architecture, the compiler
may need to know which is which to scramble the bits appropriately.
(E.g. 8+24 packing
for function gets expanded to 16+32 (in the above 48 bit case).)
It's easy to imagine that
for some combination of ingredients, if the compiler "lost track of"
the type, it could
not recover the unpacking rules. (Since dlsym(), as currently
defined, returns only one
type of pointer, it would be necessary for a compiler that knew how
to convert to provide
ALSO a "type pun" to get it to convert the data *uninterpreted* from
the return type
of dlsym() to the appropriate type.)
Donn
-----Original Message-----
From: Matt Seitz [mailto:yyyyyy@xxxxxxxxx]
Sent: Tuesday, April 16, 2002 10:25 AM
To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: Return type of dlsym
-- Marc Aurele La France <yyy@xxxxxxxxxxx> wrote:
> Given dlsym() is
> currently constrained to return a void *, it has no portable means
> returning to its caller any information about a symbol other than its
> existence/non-existence. Thus, any portable dlsym() implementation
> requires that all pointers have exactly the same representation.
> > As has already been said, a resolution of this issue should be
> two-pronged. First, the example for dlsym() should be corrected to
> comply with ISO C.
This seems a contradiction to me. If dlsym has no ISO C compatible
means of returning a function symbol's address, then how can one
construct an example that complies with ISO C? Unless you mean the
example should only show dlsym used to confirm the existance of a
function symbol?
> The last point I'd like to make is that 1003.1-2001 (or whatever you
> want to call it) was never meant to be a superset of ISO C. Rather,
> they were to align with each other, where they intersect.
This sounds a bit like Dr. Stroustrup's design philosophy for C++. A
couple of Dr. Stroustrup's guiding principles for C++ regarding C
compatability were: -"As close to C as possible, but no closer".
-"Avoid gratuitious incompatability with C"
In other words, C++ strives to be as compatible with C as it can, so
long as it doesn't mean sacrificing an important feature of C++. If an
important feature requires diverging from Standard C, then C++ does so.
But if a feature can be supported without violating Standard C, C++
follows Standard C. I would hope
that UNIX/POSIX C would have a similar philosophy.
If it truly important that one function be used for both object and
function pointers, then it makes sense to diverge from Standard C. But
I don't see a huge benefit from having just one function vs. seperate
data pointer and function pointer functions. In this case, the benefits
of Standard C compatability lead me to favor a seperate dlfsym function.
P.S. How about naming such a function "dlsym_f"? That way it would be
next to "dlsym" in an alphabetical listing.
=====
Sincerely,
Matt Seitz
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
|