1. 27 Jan, 2013 1 commit
  2. 26 Jan, 2013 4 commits
  3. 25 Jan, 2013 5 commits
  4. 24 Jan, 2013 2 commits
  5. 23 Jan, 2013 4 commits
  6. 22 Jan, 2013 1 commit
  7. 21 Jan, 2013 3 commits
  8. 20 Jan, 2013 5 commits
  9. 19 Jan, 2013 8 commits
  10. 18 Jan, 2013 7 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