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(). Chris _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
