Re: g_spawn_async incompatible api change

[Manish Singh <yosh gimp org>]

On Mon, Mar 08, 2004 at 08:45:53AM -0500, Owen Taylor wrote:
> 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. 

I'm not sure what you mean by use "as a file descriptor". GIMP keeps the
plugin pid around to waitpid/CloseHandle when done, and possibly force
kill a hung plugin.

> 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.

The tradeoff is keeping code compiling for the Win32 people without
modification vs. letting people know early on that their code will
break in Win64. The API stays as is either way, it's a question of being
lenient with people not following the API or not.

I'll fix the GIMP up regardless.

-Yosh