Closed Bug 27175 Opened 25 years ago Closed 24 years ago

Add PR_FindFunctionSymbol()

Categories

(NSPR :: NSPR, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jgmyers, Assigned: srinivas)

Details

Attachments

(1 file)

prlink.h should add the functions:

NSPR_API(void (*)()) PR_FindFunctionSymbol(PRLibrary *lib, const char *name);

NSPR_API(void (*)()) PR_FindFunctionSymbolAndLibrary(const char *name, PRLibrary 
**lib);

According to the ANSI C standard, it is not portable to cast a function pointer 
to (void *) or back.  Function pointers are allowed to be larger than data 
pointers.

The casting appears to work on all of NSPR's current platforms, but on some of 
them the compiler generates a warning when the value returned by 
PR_Find'Symbol() is cast to a function pointer.

Deferring this to NSPR 4.1 would be OK.
Status: NEW → ASSIGNED
The patch defines a new type for function pointers

typedef void (*PRFuncPtr)(void);

and two new functions

NSPR_API(PRFuncPtr) PR_FindFunctionSymbol(PRLibrary *lib, const char *name);
NSPR_API(PRFuncPtr) PR_FindFunctionSymbolAndLibrary(const char *name, PRLibrary* 
*lib);

Checked in the patch and also added the new functions to pr/tests/dlltest.c

Files modified:

/cvsroot/mozilla/nsprpub/pr/include/prlink.h,v  <--  prlink.h
new revision: 3.6; previous revision: 3.5

/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c,v  <--  prlink.c
new revision: 3.36; previous revision: 3.35

/cvsroot/mozilla/nsprpub/pr/tests/dlltest.c,v  <--  dlltest.c
new revision: 3.4; previous revision: 3.3
Marking resolved.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.1
Version: other → 4.0
I reviewed the patch and made the following changes:

Changed the PRFuncPtr type to void (*)(), to be consistent
with the type of the 'fp' field of the PRStaticLinkTable
structure.
/cvsroot/mozilla/nsprpub/pr/include/prlink.h, revision 3.7

Reverted PR_FindSymbol and PR_FindSymbolAndLibrary to their
original definition and define the new functions
PR_FindFunctionSymbol and PR_FindFunctionSymbolAndLibrary
in terms of them.  This is to minimize the risk of the new code
breaking the build on platforms that we haven't tested it on.
The only problem with this is that the cast from void* to
void (*)() may lose precision if function pointers are larger
than data pointers. 
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision 3.37
This modification breaks the solution in the first patch. The loss of 
information in the, potentially, narrowing conversion of the cast from a 
function pointer to a (void *) is the very problem that needs to be fixed here.

On some platforms such as Unix, the native function-address-lookup 
interface returns a void *, and in these cases the implementation of 
PR_FindSymbol and PR_FindFunctionSymbol can be the same.

On other platforms such as Win32, the native function-address-lookup interface 
is properly defined to return a pointer to a funtion. When the function and data 
pointers are of different size, the patch in rev 3.37 may cause the 
PR_FindFunctionSymbol to return invalid values.

If it is intended that the original implementation of PR_FindSymbol not 
be modified, then PR_FindFunctionSymbol should be implemented in parallel to 
not make incorrect conversions of the values returned by the native 
function-address-lookup interfaces.

Defining PR_FindFunctionSymbol in terms of PR_FindSymbol simply moves the 
compiler warning from the build of client code to that of NSPR code.
It is not portable to cast a function pointer
to (void *) either, so defining PR_FindSymbol
in terms of PR_FindFunctionSymbol would also
cause a compiler warning.

Cleaning up the load library API is one of
the tasks of NSPR 4.1, so there will be more
changes to come.  I'm planning to add
PR_FindDataSymbol, which returns (void *),
and have PR_FindDataSymbol and
PR_FindFunctionSymbol share the same
internal symbol lookup function (pr_FindSymbolInLib
in prlink.c) that takes a symbol type parameter,
a la the shl_findsym function of HP-UX.

I reverted your patch because it still does the
nonportable PRFuncPtr=>(void *) cast, and because
I'm planning to do more internal reorg of the
prlink.c code. Sorry if I wasn't clear.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: