Trying to answer this in simple words:
1) We can't fix this now: out of scope for a TC because it requires new
APIs.
2) We CAN fix it with a revision (or several other mechanisms that
amount to
a "patch" to the standard). However, this requires PAR approval or
its
equivalent. (Such a project could be special purpose or general
purpose.)
3) It is an XSI interface; those of us not members of TOG can only hope
to influence
TOG into making a change. It can probably be kept out of the main
POSIX standard
in its current form, but that will be harder and harder.
4) The general thrust of the interpretation is "status quo for the
future" (in terms
of the Editors Notes). That is something we can try to influence
(but see 3).
(The most the interpretation can do is say: "It says what it says,
and yes that's
broken. Here's what you do for now.... Here's what we think would
be good in
a revision... (but no promises)".)
5) Another solution is to explicitly profile the C standard (and I agree
with others
that it MUST be explicit in this case, which it's not) to require
interchange between
function and object pointers.
6) Reminder to those who propose changing the C compiler to provide some
sort of compiler
trick (and/or to suppress the warning): not everyone doing an OS has
sufficient control
over the compiler to do that. (Even within some large companies that
do both OS and
compiler, it may be effectively impossible to get the compiler
changed. If you don't
believe that, you haven't worked for a big, beaureaucratic company.)
(Only by being
very explicit in (5) can this problem begin to be solved.)
Donn
P.S. If we DO change it at all, let's also fix the error reporting so a
portable
application can determine what the error is and react to it. (Right
now, all a
strictly portable application can to is report the error as a black-box
string
and then die or go on blindly.)
-----Original Message-----
From: Clive D.W. Feather [mailto:yyyyy@xxxxxxxxx]
Sent: Wednesday, May 29, 2002 7:14 AM
To: David Korn
Cc: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: RE: ACTION 2002-5-5 dlsym() interpretation ( XSH ERN 13)
David Korn said:
> I have been following this discussion for some time and agree that the
> current interface is broken and therefore needs to be changed. I would
> also like to see this a part of POSIX as runtime linking has become
> more important over the years.
>
> However, I beleive that the current proposals does not address one of
> my concerns.
[...]
At this point I must confess myself confused. What changes are and
aren't in scope for us to make ?
Given the present signature of dlsym, it is only safe for loading
objects, not functions. The specification needs to either be limited to
data objects, or it needs some kind of wording that says functions can
be used if, and only if, the conversion to void * and back does the
right thing.
Can we add new functions ? If so, then let us invent a fixed dlsym and
deprecate the existing one, possibly in the above manner.
If we can't add new functions, then here are two possible hacks.
Does XSI allow functions to be called without the header in scope ? If
not, we can change the signature to:
void *dlsym (void *handle, const char *restrict name, ...);
with a null pointer for the second argument meaning to use a new
interface with further arguments.
Alternatively, if we can't even do that, then here's a hack: if the
second argument is NULL, the first argument is *not* a handle but a
pointer to a new structure containing all the information required for a
new interface.
In both cases, the interface would be something like this:
handle as at present
name as at present
type_wanted object/function/don't-care
type_found SET TO not-found/object/function/don't-know
object SET TO pointer to an object, or NULL
function SET TO pointer to a function, or NULL
Or is even this sort of change out of scope ?
--
Clive D.W. Feather | Work: <yyyyy@xxxxxxxxx> | Tel: +44 20 8371
1138
Internet Expert | Home: <yyyyy@xxxxxxxxxx> | Fax: +44 870 051
9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973
377646
Thus plc | | NOTE: fax number
change
|