Another short post about new APIs, this time from the upcoming 2.61.2 release. This time it’s two unrelated new APIs, which I’m covering together because they’re fairly short.
g_test_summary() is a new API along the same lines as the existing
g_test_bug() function. It’s to be called from within a unit test to provide a summary of the test to the test harness. In contrast,
g_test_bug() provides a bug reference for the unit test. In this fashion, the two can be used to provide documentation within the test code of what the test is testing, how it goes about testing it, and which bug it’s checking for regressions in. The summary passed to
g_test_summary() might be printed out as a comment in the test logs.
The summary passed to
g_test_summary() should contain a brief overview of what the test does, and should note any particularly non-obvious things about how the test is implemented.
g_test_summary ("Test g_queue_push_nth_link() with various combinations of position (before, " "in the middle of, or at the end of the queue) and various existing queues " "(empty, single element, multiple elements).");
g_test_summary ("Ensure that we successfully return IPv4 results even when they come significantly later than an IPv6 failure.");
The second API,
g_get_console_charset(), is more useful only on Windows. On Linux, it returns the same value as
g_get_charset(). On Windows, its result may differ if the console the current process is attached to has a different character encoding from that of the current locale. In those situations,
g_get_console_charset() will return something which should result in correct character decoding by the console. If the process is not attached to a console, it returns UTF-8.
When should you care? Use
g_get_console_charset() whenever you need to work out the character encoding for printing to the console (stdout or stderr), even on Linux (if you want your code to be portable). Use
g_get_charset() whenever you need the character encoding for other strings related to the system locale, such as dates or file names. GLib correctly uses the two functions internally so that you should generally never have to care (for example, you don’t need to care when you use