At 15:05 20.06.03 +0200, Sven Neumann wrote:
>Hans Breuer <[EMAIL PROTECTED]> writes:
>>  Sent to gtk-devel w/o response
>Did you file a bug-report? This is unlikely ever to be fixed without a
>> Current Gimp cvs (compiled on win32) triggers 
>> the one in g_scanner_get_char() and as a result looses
>> it's reference to the input file.
>Actually, I'd be interested to hear how exactly we are triggering
>this. When I saw your mail on gtk-devel I looked at the code in
>question but I could not find out what is going wrong.
I'm not sure if it is a win32 only thing. Without very deep
understanding of GScanner I thought it always runs to
no-more-chars-avail in g_scanner_get_char().
Maybe you can reproduce by simply checking the return value
of close() in gimp_scanner_destroy()

To reproduce I simply start and quit The Gimp. It happens
on all file in ~/.gimp13/tool-options and documents, 
sessionrc. The latter can not be written on exit cause
they are still open (on win32). This already gave an error 

>> +typedef struct _GimpScannerUserData GimpScannerUserData;
>I always wondered who invented the term user_data, can't it just be
>GimpScannerData? Apart from that (and a missing blank) the patch looks
>OK. However I'd rather see this fixed in GLib. So it should probably
>be marked with a #warning and removed later when we can depend on a
>fixed version of GLib.
Given the other use cases of GScanner I looked at (in gtk) I'm
not sure if input_fd is supposed to stay valid - they all maintain
their fd independent of it. But one could still call it a
documentation bug of GLib :-)


-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert
Gimp-developer mailing list

Reply via email to