1. 17 Dec, 2018 1 commit
  2. 28 May, 2018 1 commit
  3. 09 May, 2018 1 commit
  4. 19 Feb, 2018 1 commit
  5. 02 Nov, 2017 1 commit
  6. 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
  7. 27 Apr, 2016 1 commit
  8. 25 Nov, 2015 1 commit
  9. 16 Nov, 2015 2 commits
    • Allison Karlitskaya's avatar
      GLib: clean up the "inline" mess once and for all · db2367e8
      Allison Karlitskaya authored
      It's been a long time since we've been unconditionally saying "static
      inline" in GLib headers without complaints so it's safe to assume that
      all compilers that we care about support this.
      
      One thing that is not yet totally supported is the unadorned use of the
      word "inline".  Depending on the flags (-std=c89, for example), even GCC
      will complain about this.  Detect missing C99 support and define
      "inline" to "__inline" in that case.  Some research shows "__inline"
      appears to be the most widely-supported keyword here, but we may need to
      tweak this if we get some reports of breakage.
      
      Clean up all of the configure checks around this and define G_CAN_INLINE
      unconditionally.  Unfortunately, we must assume that some people are
      still using G_IMPLEMENT_INLINES, we must continue to implement that
      (including undefining G_CAN_INLINE and redefining G_INLINE_FUNC) if
      requested.
      
      It is not our intent to break existing users of the old-style
      G_INLINE_FUNC approach and if that has happened, we may need to make
      some further adjustments.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=757374
      db2367e8
    • Allison Karlitskaya's avatar
      gutils: clean up bit funcs inlining mess · 9834f792
      Allison Karlitskaya authored
      gutils.h and gutils.c define three utility functions as inlines that are
      also exported via the ABI.  This is done via complicated G_INLINE_FUNC
      and G_IMPLEMENT_INLINES logic.
      
      In order to be able to remove this mess, we create a another convoluted
      but slightly cleaner approach: write straight-up inline versions of the
      functions named _impl() in the header.  Define macros with the "public"
      function names that call these inlines.  From the .c file, export the
      ABI versions of these functions, implemented using the _impl() version.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=757374
      9834f792
  10. 21 Aug, 2015 1 commit
  11. 28 Jun, 2014 1 commit
  12. 31 Jan, 2014 1 commit
  13. 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
  14. 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
  15. 20 Feb, 2013 1 commit
    • Allison Karlitskaya's avatar
      win32: Drop old codepage ABI from gutils.c · 8c42a663
      Allison Karlitskaya authored
      This is a source-compatible change and only breaks ABI with respect to
      truly ancient binaries (and those binaries are already broken for other
      reasons).
      
      Back in the day, functions like g_get_user_name() used to return strings
      in the system codepage instead of utf8 (as they do today).
      
      It was decided at some point to change these functions to return utf8,
      breaking source compatibility but keeping ABI compatibility.  This was
      done by exporting new symbols with names like g_get_user_name_utf8() and
      using a #define of the old name over to the new name (so that newly
      compiled code would link against the _utf8 version, but old binaries
      would continue to use the non-utf8 variant).
      
      Meanwhile, glib has undergone several ABI breaks on Windows since, so
      those old binaries don't work anymore.
      
      Start to clean up this mess by removing the #define renaming.  New
      binaries calling g_get_user_name() will now link against
      g_get_user_name() and it will return utf8.
      
      We must keep the functions like g_get_user_name_utf8() for binary
      compatibility with recently built programs (ie: ones built with the
      renaming).  Nobody should have ever been calling these directly and of
      course they can return utf8, so just add them as internal wrappers in the
      .c file and declare them _GLIB_EXTERN there.
      
      One day, if we feel like breaking Windows ABI again, we can finish the
      cleanup by dropping the wrappers.  There is some talk of introducing
      something like 'ABI compatible for two years' and this change would be
      compatible with such a regime.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=693204
      8c42a663
  16. 13 Jan, 2013 4 commits
    • Allison Karlitskaya's avatar
      Add a new _GLIB_EXTERN macro for "extern" · b91c4768
      Allison Karlitskaya authored
      This macro simply evaluates the "extern" unless it has been explicitly
      defined to something else.
      
      All of the version macros (including the unversioned deprecation markers
      and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their
      definition.
      
      G_INLINE has also been modified to use _GLIB_EXTERN where appropriate.
      
      This macro should never be used outside of the gmacros.h/gversonmacros.h
      headers.
      
      The effect of this patch is that "extern" has now been added to all
      functions declared in installed headers.  Strictly speaking, this is
      something we should have had all along...
      
      GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on
      non-Windows, instead of "extern" which they were using before.  The
      eventual goal is to use the normal version/deprecation macros on
      exported variables and drop GLIB_VAR but we need to see how this will
      work on Windows before we go ahead with that.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=688681
      b91c4768
    • Allison Karlitskaya's avatar
      various: add GLIB_AVAILABLE_IN_ALL everywhere else · 0156092a
      Allison Karlitskaya authored
      Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
      haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
      deprecation macro).
      
      If we discover in the future that we cannot use only one macro on
      Windows, it will be an easy sed patch to fix that.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=688681
      0156092a
    • Henrique's avatar
      Add G_GNUC_PRINTF on all functions with format strings · c219181c
      Henrique authored
      This allows compilation with clang without errors, even when
      -Wformat-nonliteral is active (as long as there are no real cases of
      non literal formatting).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=691608
      c219181c
    • Benjamin Otte's avatar
      API: Constify g_get_prgname() · 120834db
      Benjamin Otte authored
      Found by Mike Gorse while via pygobject freeing the value.
      
      Should have been const according to original commit message.
      120834db
  17. 31 Dec, 2012 1 commit
  18. 28 Dec, 2012 1 commit
  19. 16 Nov, 2012 1 commit
  20. 15 Nov, 2012 1 commit
  21. 26 May, 2012 1 commit
  22. 17 Apr, 2012 1 commit
  23. 03 Nov, 2011 1 commit
  24. 20 Oct, 2011 1 commit
    • Matthias Clasen's avatar
      Deprecate g_atexit · 269acbe7
      Matthias Clasen authored
      This function was just not a good idea to begin with.
      Its documentation gives plenty of reason not to use it.
      269acbe7
  25. 17 Oct, 2011 1 commit
  26. 16 Oct, 2011 3 commits
  27. 15 Oct, 2011 2 commits
    • Matthias Clasen's avatar
      Move environment-related functions into their own files · 7a9987d3
      Matthias Clasen authored
      gutils.[hc] is a bit of a grab bag, so lets start cleaning
      things up by moving all the environment-related functions
      into separate genviron.[hc] files.
      
      The private _g_getenv_nomalloc has been moved to its sole caller.
      7a9987d3
    • Dan Winship's avatar
      gutils: Add functions for working with environment arrays · 409d9314
      Dan Winship authored
      When spawning a child process, it is not safe to call setenv() before
      the fork() (because setenv() isn't thread-safe), but it's also not
      safe to call it after the fork() (because it's not async-signal-safe).
      So the only safe way to alter the environment for a child process from
      a threaded program is to pass a fully-formed envp array to
      exec*/g_spawn*/etc.
      
      So, add g_environ_getenv(), g_environ_setenv(), and
      g_environ_unsetenv(), which act like their namesakes, but work on
      arbitrary arrays rather than working directly on the environment.
      
      http://bugzilla.gnome.org/show_bug.cgi?id=659326
      409d9314
  28. 12 Oct, 2011 1 commit
  29. 11 Oct, 2011 1 commit
  30. 09 Oct, 2011 1 commit
  31. 22 Jul, 2011 1 commit
  32. 18 Jul, 2011 1 commit
  33. 09 Jun, 2011 1 commit