On Sat, 23 Aug 2014 11:35:05 +0100 Emmanuele Bassi <eba...@gmail.com> wrote: > hi; > > On 23 August 2014 11:18, Iñigo Martínez <inigomarti...@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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
