1. 21 Sep, 2019 1 commit
    • Philip Withnall's avatar
      gatomic: Add various casts to use of g_atomic_*()s to fix warnings · 55f9c6d2
      Philip Withnall authored
      When compiling GLib with `-Wsign-conversion`, we get various warnings
      about the atomic calls. A lot of these were fixed by
      3ad375a6, but some remain. Fix them by
      adding appropriate casts at the call sites.
      
      Note that `g_atomic_int_{and,or,xor}()` actually all operate on `guint`s
      rather than `gint`s (which is what the rest of the `g_atomic_int_*()`
      functions operate on). I can’t find any written reasoning for this, but
      assume that it’s because signedness is irrelevant when you’re using an
      integer as a bit field. It’s unfortunate that they’re named a
      `g_atomic_int_*()` rather than `g_atomic_uint_*()` functions.
      
      Tested by compiling GLib as:
      ```
      CFLAGS=-Wsign-conversion jhbuild make -ac |& grep atomic
      ```
      
      I’m not going to add `-Wsign-conversion` to the set of default warnings
      for building GLib, because it mostly produces false positives throughout
      the rest of GLib.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      Fixes: #1565
      55f9c6d2
  2. 29 Aug, 2019 1 commit
  3. 02 Jul, 2019 1 commit
    • Allison Karlitskaya's avatar
      gthread: fix minor errno problem in GCond · d92f22ab
      Allison Karlitskaya authored
      The return value from `g_cond_wait_until()` is calculated, based on the
      value of `errno` after reacquiring the mutex.  This is a problem because
      `errno` can be overwritten in the case the mutex is contended (in which
      case the slow-path code will re-enter the kernel).
      
      Perform the calculation before reacquiring the mutex.
      
      See merge request GNOME/glib!958
      d92f22ab
  4. 31 May, 2019 1 commit
  5. 17 Mar, 2019 1 commit
    • Emmanuel Fleury's avatar
      Fixing signedness in glib/gthread-posix.c · 5dd02cc6
      Emmanuel Fleury authored
      In file included from glib/glibconfig.h:9,
                       from glib/gtypes.h:32,
                       from glib/gatomic.h:27,
                       from glib/gthread.h:32,
                       from glib/gthread-posix.c:42:
      glib/gthread-posix.c: In function ‘g_system_thread_new’:
      glib/gmacros.h:348:26: error: comparison of integer expressions of different signedness: ‘long int’ and ‘gulong’ {aka ‘long unsigned int’} [-Werror=sign-compare]
       #define MAX(a, b)  (((a) > (b)) ? (a) : (b))
                                ^
      glib/gthread-posix.c:1169:22: note: in expansion of macro ‘MAX’
               stack_size = MAX (min_stack_size, stack_size);
                            ^~~
      glib/gmacros.h:348:35: error: operand of ?: changes signedness from ‘long int’ to ‘gulong’ {aka ‘long unsigned int’} due to unsignedness of other operand [-Werror=sign-compare]
       #define MAX(a, b)  (((a) > (b)) ? (a) : (b))
                                         ^~~
      glib/gthread-posix.c:1169:22: note: in expansion of macro ‘MAX’
               stack_size = MAX (min_stack_size, stack_size);
                            ^~~
      5dd02cc6
  6. 31 Jan, 2019 1 commit
    • Colin Walters's avatar
      gthread: Rework to avoid holding a mutex half the time · 630fa82e
      Colin Walters authored
      This code was a persistent source of `-fsanitize=thread` errors
      when I was trying to use it on OSTree.
      
      The problem is that while I think this code is functionally correct,
      we hold a mutex during the writes, but not the reads, and TSAN (IMO
      correctly) flags that.
      
      Reading this, I don't see a reason we need a mutex at all.  At the
      cost of some small code duplication between posix/win32, we can just
      pass the data we need down into each implementation.  This ends up
      being notably cleaner I think than the awkward "lock/unlock to
      serialize" dance.
      
      (Minor review changes made by Philip Withnall <withnall@endlessm.com>.)
      
      GNOME/glib#1224
      630fa82e
  7. 06 Feb, 2018 1 commit
  8. 12 Nov, 2017 1 commit
  9. 03 Nov, 2017 1 commit
  10. 26 Oct, 2017 1 commit
  11. 24 May, 2017 1 commit
    • Sébastien Wilmet's avatar
      glib/: LGPLv2+ -> LGPLv2.1+ · f9faac76
      Sébastien Wilmet authored
      All glib/*.{c,h} files have been processed, as well as gtester-report.
      
      12 of those files are not licensed under LGPL:
      
      	gbsearcharray.h
      	gconstructor.h
      	glibintl.h
      	gmirroringtable.h
      	gscripttable.h
      	gtranslit-data.h
      	gunibreak.h
      	gunichartables.h
      	gunicomp.h
      	gunidecomp.h
      	valgrind.h
      	win_iconv.c
      
      Some of them are generated files, some are licensed under a BSD-style
      license and win_iconv.c is in the public domain.
      
      Sub-directories inside glib/:
      
      	deprecated/: processed in a previous commit
      	glib-mirroring-tab/: already LGPLv2.1+
      	gnulib/: not modified, the code is copied from gnulib
      	libcharset/: a copy
      	pcre/: a copy
      	tests/: processed in a previous commit
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776504
      f9faac76
  12. 27 Apr, 2016 1 commit
  13. 26 Apr, 2016 2 commits
  14. 29 May, 2015 1 commit
  15. 13 Mar, 2015 1 commit
  16. 26 Jan, 2015 1 commit
  17. 09 Jul, 2014 3 commits
  18. 06 Jun, 2014 1 commit
  19. 20 May, 2014 1 commit
  20. 21 Feb, 2014 1 commit
  21. 20 Feb, 2014 1 commit
    • Allison Karlitskaya's avatar
      Fix g_cond_wait_until() vs. monotonic time · 1de36e77
      Allison Karlitskaya authored
      We've had a relatively rocky path with g_cond_wait_until() on systems
      that either don't support pthread_condattr_setclock() or where
      g_get_monotonic_time() is not based on CLOCK_MONOTONIC (ie: Android and
      Mac OS).
      
      Fortunately, both of these platforms seem to share
      pthread_cond_timedwait_relative_np() which allows us to implement
      g_cond_wait_until() without races.
      
      With this patch, we now require that one of pthread_condattr_setclock()
      or pthread_cond_timedwait_relative_np() exists.  A quick look around
      suggests that this is true for all platforms that we care about.
      
      This patch removes our use of pthread_cond_timedwait_monotonic() and
      pthread_cond_timedwait_monotonic_np() which were Android-only APIs.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=673607
      1de36e77
  22. 15 Feb, 2014 1 commit
    • Matthias Clasen's avatar
      docs: let go of &ast; · bc6ee788
      Matthias Clasen authored
      Since we are no longer using sgml mode, using /&ast; &ast;/ to
      escape block comments inside examples does not work anymore.
      Switch to using line comments with //
      bc6ee788
  23. 01 Feb, 2014 3 commits
  24. 31 Jan, 2014 2 commits
  25. 26 Nov, 2013 1 commit
  26. 20 Nov, 2013 1 commit
    • Dan Winship's avatar
      Require POSIX.1 (1990) compliance on unix · 3981cddb
      Dan Winship authored
      Assume unix platforms support the original POSIX.1 standard.
      Specifically, assume that if G_OS_UNIX, then we have chown(),
      getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
      <sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
      
      Additionally, since all versions of Windows that we care about also
      have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
      
      Also remove one include of <sys/times.h>, and the corresponding
      configure check, since the include is not currently needed (and may
      always have just been a typo for <sys/time.h>).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710519
      3981cddb
  27. 04 Jul, 2013 1 commit
    • Sebastian Dröge's avatar
      gthread: Use pthread_cond_timedwait_monotonic() if available · dbdfcb69
      Sebastian Dröge authored
      Otherwise we have to rely on pthread_cond_timedwait() actually using
      the monotonic clock, which might be true or not. On Android at least
      it is using the realtime clock, no pthread_condattr_setclock() is available
      but instead pthread_cond_timedwait_monotonic() can be used.
      dbdfcb69
  28. 02 Jul, 2013 1 commit
  29. 30 Jun, 2013 2 commits
  30. 09 Apr, 2013 1 commit
  31. 04 Jan, 2013 1 commit
  32. 02 Nov, 2012 1 commit
  33. 29 Oct, 2012 1 commit