apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject [Fwd: Re: [apache-modules] apr_dso_handle_sym_t and a compiler warning (c99)]
Date Mon, 27 Feb 2006 20:03:10 GMT
One item to consider for APR 1.3 or 2.0...


-------- Original Message --------
Subject: Re: [apache-modules] apr_dso_handle_sym_t and a compiler warning (c99)
Date: Mon, 27 Feb 2006 14:25:17 -0500
From: Robert Clark <robert.clark@quest.com>
Reply-To: apache-modules@covalent.net
Organization: Quest Software Inc.
To: apache-modules@covalent.net
CC: Manfred Rebentisch <mrebentisch@comparat.de>
References: <200602260810.36869.mrebentisch@comparat.de>

On Sunday February 26, 2006 02:10, Manfred Rebentisch
<mrebentisch@comparat.de> wrote:

> in apr_dso.h is the definition:
>
> 	typedef void *                        apr_dso_handle_sym_t;
>

[ SNIP ]

> With the compiler
> 	gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)
> and the option "--std=c99" I get the warning:
>
> 	warning: ISO C forbids conversion of object pointer to function
> pointer type
>
> I think, that it could be right, to define apr_dso_handle_sym_t in
> another way:
>
> 	typedef void (*apr_dso_handle_sym_t)(void);
>
> So you generic function pointer which we can convert to other
> function pointers.

I've run into this as well.

The problem with the above change is that you can no longer use
apr_dso_sym() to dynamically access any kind of object (such as a
global variable) in the shared library. Either way, you'll get some
sort of warning.

This is due to a fundamental incompatibility between the POSIX/Win32
definition of dlsym()/GetProcAddress() and the C and C++ standard's
requirements for type conversions.

There a discussion of the problem at

   <http://www.trilithium.com/johan/2004/12/problem-with-dlsym/>

that gives a couple of potential workarounds. I'm partial to the
"union cast" method myself. If this becomes a real problem, I suspect
that the APR library could be extended to have two different types of
functions:

    apr_dso_sym_function()
    apr_dso_sym_object()

which each return the correct type for the data they are loading.
However, for right now I have learned to live with the warnings as
all the platforms I need to support (or potentially support) allow
the casting, even if the compiler complains.

- Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: apache-modules-unsubscribe@covalent.net
For additional commands, e-mail: apache-modules-help@covalent.net




Mime
View raw message