1. 26 Jan, 2013 2 commits
  2. 25 Jan, 2013 5 commits
  3. 24 Jan, 2013 2 commits
  4. 23 Jan, 2013 4 commits
  5. 22 Jan, 2013 1 commit
  6. 21 Jan, 2013 3 commits
  7. 20 Jan, 2013 5 commits
  8. 19 Jan, 2013 8 commits
  9. 18 Jan, 2013 9 commits
    • Cosimo Cecchi's avatar
      timezone: plug a memleak · 13966e0f
      Cosimo Cecchi authored
      13966e0f
    • Cosimo Cecchi's avatar
      timezone: avoid a double GBytes unref · f2459412
      Cosimo Cecchi authored
      This will cause random memory corruption; functions should not unref
      passed-in parameters.
      f2459412
    • Мирослав Николић's avatar
      4d3bb3ca
    • Allison Karlitskaya's avatar
      GVariant: fix normal-form checking for tuples · 998c6e65
      Allison Karlitskaya authored
      GVariant has the concept of fixed-sized types (ie: types for which all
      values of the type will have the same size).  Examples are booleans,
      integers, doubles, etc.  Tuples containing only these types are also
      fixed size.
      
      When GVariant is trying to deal with a fixed-sized value for which it
      doesn't have a sufficient backing store (eg: the case where a
      fixed-sized value was created with g_variant_new_data() with an
      incorrect number of bytes) it denotes this by setting the size of the
      value to the correct fixed size but using a NULL data pointer.
      
      This is well-documented in several code comments and also in the public
      API documentation for g_variant_get_data() which describes the situation
      number which NULL could be returned.
      
      The decision to deal with this case in this way was changed at the last
      minute around the time that GVariant was merged -- originally we had an
      elaborate setup involving allocating an internal buffer of sufficient
      size to be shared between all invalid values.
      
      Unfortunately, when making this change a small detail was missed.
      gvs_tuple_get_child() (the function responsible for deserialising
      tuples) was updated to properly check for this case (and it contains a
      comment about why it must).  gvs_tuple_is_normal() (the function
      responsible for verifying if a tuple is in normal form) was not.
      
      We add the check now.
      
      Note that this problem does not exist with any other container type
      because tuples are the only container capable of being fixed-sized.  All
      other container types (arrays, maybes, variants) can contain a variable
      number of items or items of variable types (note: we consider dictionary
      entries to be two-tuples).  The code for validating non-container values
      also contains a check for the case of NULL data.
      
      The problem also does not occur in the only other function dealing with
      serialised tuples: gvs_tuple_n_children().  Whereas other container
      types would have to inspect the serialised data to determine the number
      of children, for tuples it can be determined directly from the type.
      998c6e65
    • Allison Karlitskaya's avatar
      00ee6de4
    • Allison Karlitskaya's avatar
      Add new API checking utility · 614f6c5e
      Allison Karlitskaya authored
      Add a test script to make sure that (with a few exceptions) only symbols
      that start with 'g_' are being exported from our public libraries.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=692029
      614f6c5e
    • Allison Karlitskaya's avatar
      52a81a7d
    • Allison Karlitskaya's avatar
      Fix visibility for glib/ and gio/ submodules · 346aa683
      Allison Karlitskaya authored
      We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
      pcre, xdgmime, etc.) that build convenience libraries that are then
      included into libglib and libgio.  The files in these directories need
      to be built with the same visibility policy as the files in the first
      level directories, so add CFLAGS for them all.
      
      This wasn't a problem when the visibility flags were set directly in
      CFLAGS but then we had to deal with some modules that we built that we
      explicitly wanted to export symbols from.
      
      For now, we can keep things the way they are because it's less hacky and
      although it's a theoretical hazard to forget these CFLAGS, we rarely add
      new subdirectories to the build.
      346aa683
    • Colin Walters's avatar
      Remove most use of G_GNUC_INTERNAL · 6f8f1f70
      Colin Walters authored
      Now that we use an explicit list of symbols to export, the
      G_GNUC_INTERNAL is redundant.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=688681
      6f8f1f70
  10. 17 Jan, 2013 1 commit
    • Allison Karlitskaya's avatar
      Remove ABI checking scripts · dbf44729
      Allison Karlitskaya authored
      Before this commit, the only difference between the expected and actual
      ABI were the addition of _init and _fini symbols in each module (now
      that regexp-based export control is not catching those).
      dbf44729