GLib provides several macros that are used in ways which conflict with basic C syntax rules. for instance variable and function prototypes declarations roughly obey this syntax:

  TYPE_KEYWORDS FUNCTION_NAME '(' ARGUMENTS ')' ';'
  TYPE_KEYWORDS VARIABLE_NAME [ '=' INITIALIZER ] ';'

intermixing source files with statements like
  G_BEGIN_DECLS
  G_DEFINE_TYPE(someargs)
without a trailing semicolon confuses various non-compiler tools that need to operate on source in non-preprocessed form.
examples here are:
- editors with auto indentation features
- editors or viewers with syntax highlighting features
- indent
- documentation extraction tools like doxygen or c2man
- C->xxx language translators
- C code parsers for introspection needs
- probably other C code parsing tools

for reference, this topic was initially rasied and discussed in bug 351741.
a proper solution was also presented in that bug report, that is the use of macros like:
  #define G_EXTERN_C_BEGIN() extern "C" { /*}*/ void g_dummy_prototype(void)
  #define G_EXTERN_C_END()   /*{*/ }            void g_dummy_prototype(void)
which make use of the declaration
  gthread.h:extern void glib_dummy_decl (void);
which can be found in glib headers since 1.2 days, exactly for the purpose of allowing/enforcing extra semicolons in macro definitions.

unfortunately, some of the macros in quesiton like G_BEGIN_DECLS are in wide spread use, so fixing this will require a somewhat lengthy deprecation process where at first alternative macros are provided that *require* trailing semicolons, and then the original macros are deprecated. due to proper namespacing, the macros names are globally unique however, which means simple search+replace scripts can be provided to simplify the transition process.