Re: GHashTable with function pointers as values

[Chris Vine <chris cvine freeserve co uk>]

On Sat, 23 Aug 2014 11:35:05 +0100
Emmanuele Bassi <ebassi gmail com> wrote:
> hi;
>
> On 23 August 2014 11:18, Iñigo Martínez <inigomartinez gmail com>
> wrote:
> > Yes, it works, but i doesn't look like the best approach:
> >
> > warning: ISO C forbids passing argument 3 of 'g_hash_table_insert'
> > between function pointer and 'void *' [-Wpedantic]
>
> drop `-Wpedantic`: it doesn't serve any practical purposes. instead,
> identify a set of warnings that you care about, and use them.
>
> in this particular case, we're talking about undefined behaviour that
> every compiler that is not a university student project, or an arcane
> compiler for a niche architecture, supports anyway.
>
> in practice, everything that GLib supports, will also support this
> construct.

As you say, glib requires it to work because it uses this conversion
for its closures.

However, it is not just a convention about undefined behaviour which (in
practice) any modern platform will support.  It is actually defined
behaviour on any POSIX platform, because the POSIX standard _requires_
it to work, for dlsym amongst other things.  It will also work on any
windows platform, as a windows extension.

Furthermore, in C++11 (I am not sure about C11) it is not even undefined
behaviour, but implementation defined behaviour.  It is "conditionally
supported", specifically for the purpose of meeting the requirements of
POSIX:

  "Converting a pointer to a function into a pointer to an object
  type or vice versa is conditionally-supported. The meaning of such a
  conversion is implementation defined, except that if an
  implementation supports conversions in both directions, converting an
  rvalue of one type to the other type and back, possibly with
  different cv-qualification, shall yield the original pointer value." 

You can suppress the warning emitted by gcc with -Wpedantic by casting
through a union, which is also supported by gcc although it technically
breaks C99's strict aliasing rules.  But that is pointless. The direct
C-style cast which POSIX and glib requires to work, and C++11 (and maybe
C11) conditionally permits, is the way to go on this.

Chris