Overview:
The description of GOptionEntry says:
"If the arg type is G_OPTION_ARG_CALLBACK, then arg_data must point to a
GOptionArgFunc callback function."

GOptionEntry::arg_type of type gpointer (i.e. void*) is used for storing either
a pointer to a data location or a pointer to a function. This dual use violates
strict ISO C rules. If you compile glib/goption.c and glib/tests/
option-context.c with gcc version 4.4.5 with the flag -pedantic, some results
are as follows.

  CC     goption.lo
goption.c: In function ‘parse_arg’:
goption.c:1298: warning: ISO C forbids conversion of object pointer to function pointer type

  CC     option-context.o
option-context.c: In function ‘callback_test1’:
option-context.c:631: warning: ISO C forbids initialization between function pointer and ‘void *’

This violation of the ISO C rules (and the ISO C++ rules) became apparent when
I wrapped the G_OPTION_ARG_CALLBACK functionality in C++ code in glibmm. See
bug 589197 comment 11 and following comments. The glibmm code is compiled with
gcc flags -pedantic -Werror -O2 (and more flags).

There are indirect ways to convert between a function pointer and an object
pointer, but you don't want to be forced to use any of them. There are at least
two tricks that can be used with the gcc compiler (without changing the
compiler flags), but I'm not 100% sure they can be used with all other relevant
compilers.

It would be much better if glib used separate struct members for storing a
pointer to function and a pointer to object. I can see two alternatives for
GOptionEntry.

1. Make arg_data a union:
   union
   {
     gpointer dp;
     GOptionArgFunc fp;
   } arg_data;

2. Add another element to GOptionEntry:
   GOptionArgFunc arg_func;

Both alternatives break API/ABI. I don't know if there is a solution that
does not break API/ABI and conforms to the ISO C standard.

   Steps to reproduce:

   Actual results:

   Expected results:

   Build date and platform: Ubuntu 10.10, source code of glib, glibmm, etc.
      built with jhbuild on 2011-02-17.

   Additional information:
Why is C and C++ restricted in this way? Probably because there are processor
architectures where code and data reside in different address spaces. An
address to a location in code memory is not necessarily the same size as an
address to a location in data memory.

Example 1: Microchip's PIC processors (small processors for embedded
applications), where a code address can be 12 bits and a data address 8 bits
(just an example, it differs between models).

Example 2: 16-bit Intel processors in some memory models, where a data address
can be 16 bits, a code address 20 or 32 bits.

Probably these examples are not relevant to glib, but they show, I believe,
why the C and C++ standards draw a sharp dividing line between the two groups
of addresses.