On Tue, 27 May 2014 10:24:26 +0100 Chris Vine <ch...@cvine.freeserve.co.uk> wrote: > On Mon, 26 May 2014 15:03:47 -0400 > Phillip Susi <ps...@ubuntu.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 05/22/2014 12:52 PM, Kjell Ahlstedt wrote: > > > The gtkmm tutorial contains a section that describes how to use > > > the gdb debugger to see where an exception is thrown in a signal > > > handler. > > > > > > https://developer.gnome.org/gtkmm-tutorial/stable/sec-exceptions-in-signal-handlers.html.en > > > > Thanks... so it seems the problem is that Glib::IOChannel::read() is > > throwing the exception because dosfsck is spitting out a 0xBD > > character. It seems that in CP 437, that is a 1/2 chracter, but in > > UTF-8 it is an incomplete multi byte sequence. This leads me to > > conclude that there is a bug in glibmm, and I have a question on how > > to handle this character. The question is how to have > > IOChannel::read treat its input as CP-437 instead of UTF-8, and the > > bug: > > > > glibmm seems to have an automatic exception catch that prints a > > warning and attempts to continue. This is wrong. An unhandled > > exception should terminate the program. By eating the exception, > > glibmm has caused gparted's call stack to unwind leaving the program > > in a broken state. > > If you set the IOChannel's encoding to "" using > Glib::IOChannel::set_encoding() immediately after creation it should > accept binary data. Are you saying that that doesn't work? If it > doesn't it is certainly a bug, as it works with the unwrapped > g_io_channel_set_encoding() when passed a NULL argument. (In which > case, I guess you could use g_io_channel_set_encoding() on the > underlying GIOChannel object.) > > However, if you have a file descriptor and you are handling binary > data why use a IOChannel at all? Why not connect the file descriptor > to the main loop using Glib::signal_io().connect() and read the file > descriptor using standard (unix) read().
Two subsidiary thoughts: as an alternative have you tried setting the encoding to CP437? iconv() supports it on my system so glib ought to also. Secondly, on the issue of exceptions, if you are reading the IOChannel in a callback in the glib main loop I suspect glibmm is swallowing the exception in order to protect the main loop, although I haven't looked at glibmm's wrapper for executing callbacks in the main loop for some time so I could be wrong. It is often better to swallow a throwing callback and print to g_critical() than terminate the program, as you can use g_log_set_always_fatal() to change the behaviour if you want. If I am right about glibmm protecting the main loop, I would be surprised if by swallowing the exception, glibmm caused gparted's call stack to unwind. You would expect that to do the opposite (and exceptions can't propagate through glib's C layer to unwind the stack anyway), albeit as you say probably rendering the program useless. Chris _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
