Whether or not the compiler is required to generate a warning or not seems
to be beside the point. The question is more one of whether the type
casting required by the function definition is safe or portable.
Option #2/#3 seems to be consistent with practice elsewhere in the
standard and would result in no real change in most implementations
(i.e. fptr_t could be defined as void*). Further, it would be trivial for
an autoconf-like script to generate appropriate typedefs if the platform
does not have them.
On Mon, 15 Apr 2002, Don Cragun wrote:
> Andrew,
> I raised this issue on a different alias (OGTGbase email
> sequence #3613) on December 17, 1999. Discussion on the topic
> continued for a while until Dave Prosser argued:
> BUT, there is no *requirement* (or expectation either,
> in my opinion) that a compiler wll complain about casts
> between "void*"s and a function pointer.
> and interpreted enough quotes from the 1999 C standard to back it up.
> After lengthy internal discussions between our C and C++ language
> experts, we agreed that there is no requirement that a C compiler
> generate a warning. (But, a C++ compiler is required to generate a
> warning in this case. Since there were no plans for a C++ binding to
> the AGR, we dropped the issue.)
> If the group now believes that a C++ binding is needed, our
> proposal at that time was to:
> 1. Deprecate dlsym().
> 2. Add type fptr_t to <dlfcn.h> with the following requirements:
> (1) The fptr_t type shall be a scalar type.
> (2) It shall be possible to cast any function pointer type to
> the type fptr_t.
> (3) It shall be possible to cast an fptr_t type to any function
> pointer type.
> (4) If a function pointer is cast to the type fptr_t and the
> resulting value is subsequently cast back to the type of
> the original function pointer, the resulting value shall be
> the original function pointer value.
> 3. Add functions dldsym() and dlfsym() with synopses:
> #include <dlfcn.h>
> void *dldsym(void *handle, const char *name);
> fptr_t dlfsym(void *handle, const char *name);
> with DESCRIPTION:
> The dldsym() and dlfsym() functions allow a process to obtain
> the address of the symbol specified by the \fIname\fP argument from
> the executable object file referenced by \fIhandle\fP (see
> dlopen()). The dldsym() function obtains the address of data
> symbols; the dlfsym() function obtains the address of function
> symbols. The application shall provide a \fIhandle\fP argument that
> was returned by a successful call to dlopen() that has not yet
> been closed (see dlclose()).
>
> These functions shall search for the named symbol in all
> objects loaded automatically as a result of loading the object
> referenced by \fIhandle\fP. \fILoad ordering\fP as described in
> dlopen() shall be used in operations upon the global symbol
> object. The symbol resolution algorithm used shall be
> \fIdependency order\fP as described in dlopen().
> and RETURN VALUE description:
> On successful completion, dldsym() and dlfsym() shall return a
> pointer to the object named by \fIname\fP.
>
> If \fIhandle\fP does not refer to a valid executable object
> file handle returned by dlopen(), or if the named symbol does
> not refer to a data object found within any of the objects
> associated with \fIhandle\fP, dldsym() shall return NULL. If
> \fIhandle\fP does not refer to a valid executable object file
> handle returned by dlopen(), or if the named symbol does not
> refer to a function object found within any of the objects
> associated with \fIhandle\fP, dlfsym() shall return NULL. More
> detailed diagnostic information shall be available through
> dlerror().
> Given current namespace reservation rules, we'd also be happy to
> propose posix_dldsym() and posix_dlfsym() as alternative names for
> these functions.
>
> Thanks,
> Don
>
> >From yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx Sun Apr 14 00:01:22 2002
> >Resent-Date: 14 Apr 2002 07:00:14 -0000
> >From: Andrew Josey <yyyyyy@xxxxxxxxxxxxxxxxx>
> >To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >Subject: Re: Return type of dlsym
> >Resent-Message-ID: <yyyyyyyyyyyyyyyy@xxxxxxx>
> >Resent-To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >Resent-From: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >X-Mailing-List: austin-group-l:archive/latest/3759
> >X-Loop: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >Resent-Sender: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
> >
> >All
> >This issue seems vaguely familiar, or similar to one we have
> >discussed before.
> >
> >On a procedural note can someone please report a defect for this,
> >we will be approaching the cutoff for Defect Reports that can be
> >considered for the May meeting.
> >
> >Thanks
> >Andrew
> >
> >-----
> >Andrew Josey The Open Group
> >Austin Group Chair Apex Plaza,Forbury Road,
> >Email: yyyyyyy@xxxxxxxxxxxxx Reading,Berks.RG1 1AX,England
> >Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110
>
>
--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.
yyyyyyy@xxxxxxxx toll-free: 888-771-3538 RTP area: 919-816-9901
|