At 15:05 20.06.03 +0200, Sven Neumann wrote: >Hi, > >Hans Breuer <Hans@xxxxxxxxxx> writes: > >> Sent to gtk-devel w/o response > >Did you file a bug-report? This is unlikely ever to be fixed without a >bug-report. > >> 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 message. >> +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 -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
