Re: g_spawn_async incompatible api change

[Owen Taylor <otaylor redhat com>]

On Sun, 2004-03-07 at 18: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
> 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 ?

Ugh. I was hoping this would be a "harmless" warning in MSVC as it is
for GCC. If you try to *use* a GPid as a file descriptor, then you get
into big difficulties, so I'd really rather people fixed up their code. 

The question to me isn't really "is this API breakage?" (on Windows,
with MSVC) but rather  "do we care that it is API breakage?". And I'm
not sure I'm in a good position to answer that.

But if it was up to me, I'd say that we should keep the API breakage
rather than keeping the broken API.

Regards,
						Owen