Re: g_spawn_async incompatible api change

On 2004.03.07 23:03 Hans Breuer wrote:
Compiling The Gimp reveals that the recently added GPid (== void*)
may be not such a good idea :

D:\devel\my-gtk\gimp\app>nmake -nologo -f makefile.msc sub-one THIS=plug-in
	cd plug-in
	nmake -nologo -f makefile.msc
cl -G5 -Zi -MD -W3 -nologo -FImsvc_recommended_pragmas.h -I..\.. -I..\../app -I..\..\..\glib -I..\..\..\glib\glib -I..\..\..\glib\gmodule -I..\..\..\other\intl-tml -I ..\..\../atk -I..\..\../gtk+\gdk -I..\..\../gtk+ -I..\..\..\pango -I..\..\../atk -GD -c plug-in.c
plug-in.c(450) : error C4047: 'function' : 'void ** ' differs in levels of indirection from 'int *' plug-in.c(450) : warning C4022: 'g_spawn_async' : pointer mismatch for actual parameter 7

How do we fix this ?
Changing it back to "typedef GPid int" in glibconfig.h ?

Silly question: Do we need to? It will be binary compatible, just not
API compatble. Is Gtk+ 2.4.0 guaranteed to be compatible with any
program written against the 2.2 API?

If we do need to change it, then I think "int" is the best option.
We'll have to aim to make Gtk+ 3.0 compatible with 64-bit MS-Windows
and accept that Gtk+ 2.x will never work with it.

There are other options:

We could change g_spawn* back to "int *" and set a value that g_child_watch
and g_spawn_close_pid would recognize but that might not be a valid handle.

Frankly, I think this kind of hacking is just storing up trouble for later.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]