1. 15 Oct, 2011 1 commit
  2. 13 Oct, 2011 2 commits
  3. 12 Oct, 2011 1 commit
  4. 11 Oct, 2011 1 commit
  5. 09 Oct, 2011 1 commit
  6. 06 Oct, 2011 4 commits
  7. 05 Oct, 2011 1 commit
    • Dan Williams's avatar
      closure: fix handling of ENUMs and integral return types on 64-bit BE platforms · 8e82225a
      Dan Williams authored
      enums are stored in v_long but need to be marshalled as signed
      integers.  On platforms where int is 32 bits, taking the
      address of v_long resulted in the wrong 32 bits being marshalled.
      So we need to stuff the enum's int-sized value to a temporary
      int-sized variable and marshall that instead.
      
      Second, on return, libffi actually returns a pointer to a value
      that's sized according to platform conventions, not according to
      what the caller requested.  ie if ffi_type_sint was requested, the
      value can still be a 64-bit sign-extended long on a 64-bit
      architecture like PPC64, thus the caller cannot simply cast
      the return value as a pointer to the desired type, but must cast
      as a pointer to an integral type and then cast to the desired
      type to remove any sign extension complications.
      
      For more information on how to correctly handle libffi return
      values, see the following bug, specifically comment 35:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=736489
      
      "For 64-bit ABIs that extend integral returns types to 64-bits, libffi always
      returns full 64-bit values that you can truncate in the calling code.   It's
      just the way it is has always been.  Please don't change libffi.  I'll document
      this clearly for the next version (perhaps there is a mention of this, I
      haven't looked yet).
      
      The same is true for returning 8-bit values, for instance, on 32-bit systems.
      All ABIs extend those results to the full 32-bits so you need to provide a
      properly aligned buffer that's big enough to hold the result."
      
      https://bugzilla.gnome.org/show_bug.cgi?id=659881
      8e82225a
  8. 04 Oct, 2011 3 commits
  9. 03 Oct, 2011 1 commit
  10. 28 Sep, 2011 3 commits
  11. 23 Sep, 2011 1 commit
  12. 22 Sep, 2011 2 commits
  13. 21 Sep, 2011 3 commits
  14. 09 Sep, 2011 1 commit
    • Dan Winship's avatar
      Make threads mandatory · 5bc7729d
      Dan Winship authored
      G_THREADS_ENABLED still exists, but is always defined. It is still
      possible to use libglib without threads, but gobject (and everything
      above it) is now guaranteed to be using threads (as, in fact, it was
      before, since it was accidentally impossible to compile with
      --disable-threads).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=616754
      5bc7729d
  15. 05 Sep, 2011 1 commit
  16. 31 Aug, 2011 1 commit
  17. 29 Aug, 2011 1 commit
    • Matthias Clasen's avatar
      Spelling fixes · 1b28408b
      Matthias Clasen authored
      Spelling fixes in comments and docs, provided by
      Kjartan Maraas in bug 657336.
      1b28408b
  18. 21 Aug, 2011 1 commit
  19. 19 Aug, 2011 2 commits
  20. 17 Aug, 2011 1 commit
  21. 13 Aug, 2011 2 commits
  22. 11 Aug, 2011 1 commit
  23. 08 Aug, 2011 1 commit
  24. 22 Jul, 2011 1 commit
  25. 21 Jul, 2011 1 commit
    • Allison Karlitskaya's avatar
      GParam: try to avoid further invalid uses · 706b2751
      Allison Karlitskaya authored
      In an attempt to avoid some potential future abuses of the GParamSpec
      API, qualify the 'name' field of the structure as 'const' and add a
      comment noting that it is an interned string.
      
      This is a theoretical API break, but it will only ever result in
      warnings -- and even then, only if you were already doing something
      questionable.
      
      Clean up some of the warnings that were caused internally in gparam.c
      from these changes.
      706b2751
  26. 19 Jul, 2011 1 commit
  27. 15 Jul, 2011 1 commit