Warning with Lua 5.1.3 sources (gcc -pedantic)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Warning with Lua 5.1.3 sources (gcc -pedantic)

Asko Kauppi

There is a line in Lua sources, which gives warning with gcc '- pedantic' compiler option.

Has anyone found a suitable solution to this?

  lua_CFunction f = (lua_CFunction)dlsym(lib, sym);

>loadlib.c: In function ‘ll_sym’:
>loadlib.c:77: warning: ISO C forbids conversion of object pointer to function pointer type

Did some googling, and:

http://www.webservertalk.com/message217658.html

Which does not really show a clear solution, does it?

-asko



Reply | Threaded
Open this post in threaded view
|

Re: Warning with Lua 5.1.3 sources (gcc -pedantic)

eugeny gladkih
>>>>> "AK" == Asko Kauppi <[hidden email]> writes:

 AK> There is a line in Lua sources, which gives warning with gcc '-
 AK> pedantic' compiler option.

 AK> Has anyone found a suitable solution to this?

 AK>   lua_CFunction f = (lua_CFunction)dlsym(lib, sym);

 >> loadlib.c: In function âll_symâ:
 >> loadlib.c:77: warning: ISO C forbids conversion of object pointer to 
 AK> function pointer type

 AK> Did some googling, and:

 AK> http://www.webservertalk.com/message217658.html

 AK> Which does not really show a clear solution, does it?

C++ example is following, I guess it's not easy for plain C

template<class To, class From> inline To depun_ptr( From f ) {
#if defined( _MSC_VER )
  return (To)f;
#else
  union { From f; To t; } u;
  u.f = f;
  return u.t;
#endif
}

  // get rid of idiotic g++ warning
  template<class T> T symbol( const char *symbol_name ) const {
    return depun_ptr<T>( get_symbol( symbol_name ) );
  }

get_symbol is some wrapper for dlsym():

void *dynamic_library_t::get_symbol( const char *symbol_name ) const {
#if defined( _WIN32 )
  return (void*) GetProcAddress( lib_handle, symbol_name );
#elif defined( __hpux )
  void* symb;

  if( shl_findsym( (shl_t *)(&lib_handle),
		   symbol_name,
		   TYPE_UNDEFINED,
		   &symb ) != 0 )
    return 0;
  
  return symb;
#else
  return dlsym( lib_handle, symbol_name );
#endif
}

I hope the idea is clean

-- 
Yours sincerely, Eugeny.
Doctor Web, Ltd. http://www.drweb.com
+79119997425


Reply | Threaded
Open this post in threaded view
|

Re: Warning with Lua 5.1.3 sources (gcc -pedantic)

Luiz Henrique de Figueiredo
In reply to this post by Asko Kauppi
> Did some googling, and:
> 
> http://www.webservertalk.com/message217658.html
> 
> Which does not really show a clear solution, does it?

A followup to that message gives a solution, which is also not very clean:

  http://groups.google.com/group/comp.unix.programmer/msg/de36b126ba703795

Reply | Threaded
Open this post in threaded view
|

Re: Warning with Lua 5.1.3 sources (gcc -pedantic)

Bennett Todd
In reply to this post by Asko Kauppi
2008-03-12T19:30:53 Asko Kauppi:
> >loadlib.c:77: warning: ISO C forbids conversion of object pointer to function pointer type

I have no sure knowledge of why that constraint is there,
but it _sounds_ like it's to accomodate portability
to Harvard Architecture systems, which I checked at
<URL:http://en.wikipedia.org/wiki/Harvard_architecture> before
posting this to check my memory, and found that article fascinating.
It suggests where {code<=>data} dynamic language implementations
are gonna be hard to port, and offers hints about what performance
hits an implementor needs to worry about dodging on current
architectures. The performance question is probably most important
when thinking about memory layout of closures, would be my guess.
Code loaders probably needn't think about it.

-Bennett

Attachment: pgpqc_ehio2Br.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Warning with Lua 5.1.3 sources (gcc -pedantic)

Miles Bader
In reply to this post by eugeny gladkih
eugeny gladkih <[hidden email]> writes:
>   // get rid of idiotic g++ warning
>   template<class T> T symbol( const char *symbol_name ) const {
>     return depun_ptr<T>( get_symbol( symbol_name ) );
>   }

It can be annoying to be sure, but I'm not sure if "idiotic" is fair --
the standard really does say the two pointer types aren't compatible
(and there are reasons for that).  If you use the -pedantic option, well
the compiler is pedantic.... :-)

To get around the warning in C though, you could just use an
intermediary integer type, hopefully something long enough to hold a
pointer, e.g., intptr_t:

 #include <stdint.h>

    void *dptr = ...;
    void (*fptr)() = (void (*)())(intptr_t)dptr;

That doesn't give a warning with gcc -pedantic, unless "intptr_t" is a
different size than a function pointer, in which case it will give a
warning (which is probably what you want).

-Miles

-- 
Absurdity, n. A statement or belief manifestly inconsistent with one's own
opinion.

Reply | Threaded
Open this post in threaded view
|

Re: Warning with Lua 5.1.3 sources (gcc -pedantic)

eugeny gladkih
>>>>> "MB" == Miles Bader <[hidden email]> writes:

 MB> To get around the warning in C though, you could just use an
 MB> intermediary integer type, hopefully something long enough to hold a
 MB> pointer, e.g., intptr_t:

sometimes it's impossible to find such integer type don't using
autoconf or so. the union is convient enough. casting to the integer
and back to the pointer is not better in other meaning, too. the
pointer to the data and the pointer to the code could be different
completely.

-- 
Yours sincerely, Eugeny.
Doctor Web, Ltd. http://www.drweb.com
+79119997425

Reply | Threaded
Open this post in threaded view
|

Re: Warning with Lua 5.1.3 sources (gcc -pedantic)

Tony Finch
In reply to this post by Asko Kauppi
On Wed, 12 Mar 2008, Asko Kauppi wrote:
>
>  lua_CFunction f = (lua_CFunction)dlsym(lib, sym);
>
> > loadlib.c: In function ‘ll_sym’:
> > loadlib.c:77: warning: ISO C forbids conversion of object pointer to
> > function pointer type

In this case the solution is to use dlfunc() instead, though not all
systems have extended the dynamic linker API this way.

The other point worth noting is that dlsym() is a POSIX function and POSIX
makes much stricter guarantees about the underlying machine architecture
than C does, so the warning doesn't matter on POSIX. However I agree that
warning cleanliness is something to aim for.

Tony.
-- 
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
SOLE: SOUTHWESTERLY BACKING EASTERLY FOR A TIME 4, INCREASING 5 TO 7. ROUGH OR
VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.