Issue 22371 - osl API requires clients to use illegal pointer conversions
Summary: osl API requires clients to use illegal pointer conversions
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0
Assignee: joerg.barfurth
QA Contact: issues@porting
URL:
Keywords:
Depends on:
Blocks: 22046
  Show dependency tree
 
Reported: 2003-11-12 09:06 UTC by joerg.barfurth
Modified: 2004-02-12 12:56 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description joerg.barfurth 2003-11-12 09:06:32 UTC
There are several osl APIs that relate to symbols within shared libraries and
that require symbol addresses to be passed as void*.

Frequently these APIs need to be used with function symbols, so clients need to
convert parameters or results between void* and function pointers. Such
conversions are illegal in C++ (and potentially even in C).

Even though compilers can be made to do the required conversion, this forces use
of C-Style casts and produces warnings at higher warning levels. There may even
exit platforms, where this ceases to work at all.

This portability issue should be encapsulated in sal, to shield client code from
that problem and allow a global reduction of warnings. All osl functions that
work on symbol adresses should provide two signatures, one of which supports
function pointers.

Suggested header additions:

osl/module.h:
    typedef void (*oslGenericFunction)(void);

    oslGenericFunction SAL_CALL 
    osl_getFunctionSymbol(oslModule Module, rtl_uString *strSymbolName);

    sal_Bool SAL_CALL 
    osl_getModuleURLFromFunctionAddress( oslGenericFunction pf, 
                                         rtl_uString **pustrURL );

osl/module.hxx:	
    oslGenericFunction SAL_CALL osl::Module::
    getFunctionSymbol( const ::rtl::OUString& strSymbolName);

    static sal_Bool SAL_CALL osl::Module::
    getUrlFromAddress(oslGenericFunction addr, ::rtl::OUString & libraryUrl);

Note: The inconsistency in the spelling of URL/Url was copied from existing APIs.
Comment 1 tino.rachui 2003-11-13 10:15:06 UTC
Hi Gorden,

it's your now :-)
JB already gave some suggestions on how to resolve this issue (see
above). Feel free to ask me in case of questions.

Kind Regards,
Tino
Comment 2 tino.rachui 2003-11-13 12:31:19 UTC
i22046 depends on this issue
Comment 3 joerg.barfurth 2003-11-13 13:35:34 UTC
Should use IZ dependency to reflect that
Comment 4 gorden.lin 2003-11-27 08:14:09 UTC
OK, issue accepted and undergoing, new to IZ, forgot to give this
message:-).thanks JB and Tino's description.
Comment 5 gorden.lin 2003-12-18 08:23:43 UTC
source code of this bug has been completed and reviewed, Tino will check in the
source and care for this. 
Comment 6 tino.rachui 2003-12-18 11:16:10 UTC
Now there are some additional functions in osl/module which accept or return a
generic function pointer instead of a data pointer, e.g.
osl_getFunctionAddress or osl_getModuleURLFromFunctionAddress. Appropriate
inline wrapper are available as well.
Comment 7 tino.rachui 2004-01-27 15:02:53 UTC
Set to verified
Comment 8 tino.rachui 2004-02-11 20:27:25 UTC
Verified on head revision.
Comment 9 joerg.barfurth 2004-02-12 12:54:57 UTC
Marking as resolved again
Comment 10 joerg.barfurth 2004-02-12 12:56:01 UTC
Marking as verified again
Comment 11 joerg.barfurth 2004-02-12 12:56:45 UTC
Closing