1. 12 Oct, 2015 1 commit
  2. 19 Aug, 2015 1 commit
  3. 12 May, 2015 1 commit
  4. 11 Oct, 2014 2 commits
  5. 08 Aug, 2014 2 commits
  6. 28 Jun, 2014 1 commit
  7. 25 Jun, 2014 1 commit
  8. 09 Jun, 2014 1 commit
  9. 06 Jun, 2014 1 commit
  10. 01 Jun, 2014 1 commit
  11. 31 May, 2014 1 commit
  12. 29 Apr, 2014 1 commit
  13. 01 Feb, 2014 3 commits
  14. 31 Jan, 2014 3 commits
  15. 20 Nov, 2013 1 commit
    • Dan Winship's avatar
      Require C90 compliance · 6e4a7fca
      Dan Winship authored
      Assume all supported platforms implement C90, and therefore they
      (correctly) implement atexit(), memmove(), setlocale(), strerror(),
      and vprintf(), and have <float.h> and <limits.h>.
      
      (Also remove the configure check testing that "do ... while (0)" works
      correctly; the non-do/while-based version of G_STMT_START and
      G_STMT_END was removed years ago, but the check remained. Also, remove
      some checks that configure.ac claimed were needed for libcharset, but
      aren't actually used.)
      
      Note that removing the g_memmove() function is not an ABI break even
      on systems where g_memmove() was previously not a macro, because it
      was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
      it would have been glib-internal since 2004.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710519
      6e4a7fca
  16. 27 Aug, 2013 1 commit
    • Dan Winship's avatar
      gtype: fix a no-op assertion · 34e1a537
      Dan Winship authored
      g_type_class_add_private() was doing
      
          g_assert (node->data->instance.private_size <= 0xffff);
      
      but that field is a guint16, so the check was a no-op. (Noticed by
      clang, but not gcc for some reason.) Fix it to do the math in a gssize
      variable and do the bounds checking there before updating the struct
      field.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=706888
      34e1a537
  17. 04 Aug, 2013 1 commit
  18. 24 Jun, 2013 1 commit
    • Emmanuele Bassi's avatar
      Allow registering instance private data during get_type() · d3dec6ec
      Emmanuele Bassi authored
      For static types, it should be possible to register a private data
      structure right when we are registering the type, i.e. from the
      get_type() implementation. By allowing this, we can take advantage of
      the existing type definition macros to cut down the amount of code
      necessary (as well as the knowledge baggage) when creating a new type.
      
      The main issue with this new feature is that it cannot be mixed with the
      old idiomatic way of adding private instance data by calling a function
      in the middle of the class_init() implementation, as that imposes the
      additional constraint of initializing the whole type hierarchy in order
      to retrieve the offset of the private data in the GTypeInstance
      allocation.
      
      For this reason we are going to follow a two-step process; in the first
      step, we are going to introduce the new (semi-private) API to register
      the intent to add private instance data from within the get_type()
      implementation, and hide it behind a macro; at the same time, the
      G_DEFINE_TYPE_EXTENDED macro is going to be modified so that it will
      register the private instance data if the macro was used, using a new
      (semi-private) function as well. Once we have migrated all our code, we
      will make the first new function perform the actual private data
      registration, and turn the second new function into a no-op. This should
      guarantee a transparent migration of existing code to the new idiomatic
      form.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=700035
      d3dec6ec
  19. 29 May, 2013 2 commits
  20. 21 May, 2013 1 commit
    • Dan Winship's avatar
      Use 'dumb quotes' rather than `really dumb quotes' · 4b94c083
      Dan Winship authored
      Back in the far-off twentieth century, it was normal on unix
      workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
      APOSTROPHE to be drawn as "’". This led to the convention of using
      them as poor-man's ‛smart quotes’ in ASCII-only text.
      
      However, "'" is now universally drawn as a vertical line, and "`" at a
      45-degree angle, making them an `odd couple' when used together.
      
      Unfortunately, there are lots of very old strings in glib, and also
      lots of new strings in which people have kept up the old tradition,
      perhaps entirely unaware that it used to not look stupid.
      
      Fix this by just using 'dumb quotes' everywhere.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=700746
      4b94c083
  21. 23 Apr, 2013 2 commits
  22. 22 Apr, 2013 3 commits
    • Allison Karlitskaya's avatar
      Revert "GObject: prevent installing properties after init" · e8438f98
      Allison Karlitskaya authored
      This reverts commit ddb0ce14.
      
      Colin's smoke testing has found issues in at least gjs and
      gnome-settings-daemon.  We'll need to see if we can address those.
      e8438f98
    • Allison Karlitskaya's avatar
      GObject: prevent installing properties after init · ddb0ce14
      Allison Karlitskaya authored
      GObject has previously allowed installing properties after class_init
      has finished running.  This means that you could install some of your
      own properties on G_TYPE_OBJECT, for example, although they wouldn't
      have worked properly.
      
      Prevent this from happening.  Require that all properties are installed by
      the time class_init has finished.
      
      Complaints go to this bug:
      
      https://bugzilla.gnome.org/show_bug.cgi?id=698614
      ddb0ce14
    • Allison Karlitskaya's avatar
      gtype: put private data before the instance · 31fde567
      Allison Karlitskaya authored
      Classically, a GTypeInstance has had the following layout:
      
       [[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]
      
      where TypeB is a subclass of TypeA which is a GObject.  Both TypeA and
      TypeB use pivate data.
      
      The main problem with this approach is that the offset between a pointer
      to an instance of TypeA and the TypeAPrivate is not constant: it changes
      depending on the depth of derivation and the size of the instance
      structures of the derived types.  For example, changing the size of the
      TypeB structure in the above example would push the TypeAPrivate further
      along.
      
      This complicates the implementation of g_type_instance_get_private().
      In particular, during object construction when the class pointer to the
      'complete type' of the object is not yet stored in the header of the
      GTypeInstance, we need a lookup table in order to be able to implement
      g_type_instance_get_private() accurately.
      
      We can avoid this problem by storing the private data before the
      structures, in reverse order, like so:
      
        [TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]
      
      Now the distance between TypeA and TypeAPrivate depends only on the size
      of GObject and GTypeInstance, which are static.  Even in the case of
      TypeB, the distance is not statically known but can be determined at
      runtime and is constant (because we will know the size of TypeAPrivate
      by the time we initialise TypeB and it won't change).
      
      This approach requires a slighty dirty trick: allocating extra memory
      _before_ the pointer we return from g_type_create_instance().  The main
      problem with this is that it will cause valgrind to behave very badly,
      reporting almost everything as "possibly lost".
      
      We can correct for this by including a few valgrind client requests in
      order to inform it that the start of the GTypeInstance should be
      considered a block of memory and that pointers to it should mean that
      this block is reachable.  In order to make the private data reachable,
      we also declare it as a block and include an extra pointer from the end
      of the primary block pointing back at it.  All of this is only done if
      we are running under Valgrind.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=698595
      31fde567
  23. 04 Apr, 2013 2 commits
  24. 07 Feb, 2013 1 commit
  25. 04 Jan, 2013 2 commits
  26. 01 Jan, 2013 1 commit
  27. 18 Dec, 2012 2 commits