1. 20 Nov, 2018 1 commit
  2. 15 Jan, 2018 3 commits
  3. 15 Nov, 2017 2 commits
  4. 27 Sep, 2017 1 commit
  5. 07 Apr, 2017 1 commit
  6. 13 Oct, 2016 3 commits
    • Simon McVittie's avatar
      Add missing function attributes suggested by clang (but not by gcc) · 7959d907
      Simon McVittie authored
      clang is a little more enthusiastic about suggesting these.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      7959d907
    • Simon McVittie's avatar
      Clean up how we arrange for environ to be declared · 91ae697d
      Simon McVittie authored
      Annoyingly, the POSIX way to declare environ (as
      "extern char **environ") is a redundant declaration in glibc with
      _GNU_SOURCE; work around that.
      
      We also have a workaround for _NSGetEnviron() needing to be used
      instead of direct access to environ in at least some circumstances on
      Mac OS. Attempt to sync that up between all the files that use environ,
      consistently sorting the most special special-cases first (Windows
      for files that are compiled there, then Mac, then GNU, with
      lowest-common-denominator POSIX last).
      
      The affected files are already OS-specific, so I'm not bothering to
      introduce a nicer or higher-level API for this.
      
      Based on the best bits of an earlier patch from me, and an earlier
      patch from Thomas Zimmermann.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: default avatarThomas Zimmermann <tdz@users.sourceforge.net>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
      91ae697d
    • Simon McVittie's avatar
      Be more const-correct · 8db5ca90
      Simon McVittie authored
      As a general design principle, strings that we aren't going to modify
      should usually be const. When compiling with -Wwrite-strings, quoted
      string constants are of type "const char *", causing compiler warnings
      when they are assigned to char * variables.
      
      Unfortunately, we need to add casts in a few places:
      
      * _dbus_list_append(), _dbus_test_oom_handling() and similar generic
        "user-data" APIs take a void *, not a const void *, so we have
        to cast
      * For historical reasons the execve() family of functions take a
        (char * const *), i.e. a constant pointer to an array of mutable
        strings, so again we have to cast
      * _dbus_spawn_async_with_babysitter similarly takes a char **,
        although we can make it a little more const-correct by making it
        take (char * const *) like execve() does
      
      This also incorporates a subsequent patch by Thomas Zimmermann to
      put various string constants in static storage, which is a little
      more efficient.
      Signed-off-by: default avatarSimon McVittie <smcv@debian.org>
      Reviewed-by: default avatarThomas Zimmermann <tdz@users.sourceforge.net>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
      8db5ca90
  7. 30 Sep, 2016 2 commits
  8. 30 Jun, 2016 1 commit
  9. 20 May, 2016 1 commit
  10. 27 Nov, 2015 1 commit
    • Simon McVittie's avatar
      Do not attempt to call child_setup on Windows · 420f3474
      Simon McVittie authored
      child_setup() is defined to be called after fork() and before exec(),
      but Windows' process model does not have fork(): the equivalent of
      those two operations is a single CreateProcess() call. This means
      that there is no point at which we could call child_setup() and
      have it affect only the child's process-global state. At the point
      where it is currently executed, it affects the parent's process-global
      state instead, which would be actively harmful if we used any
      child_setup() function that was not a no-op on Windows.
      
      The equivalent function in GLib, g_spawn_async_with_pipes(), documents
      child_setup() as unused on Windows. Do the same here.
      
      In practice, our only use of child_setup() outside tests
      is #ifdef DBUS_UNIX anyway, so this change has no practical effect
      right now.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=85857Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      420f3474
  11. 12 May, 2015 1 commit
  12. 24 Mar, 2015 1 commit
  13. 11 Mar, 2015 2 commits
  14. 06 Nov, 2014 1 commit
  15. 29 Oct, 2014 1 commit
  16. 10 Jan, 2014 1 commit
  17. 27 Nov, 2013 1 commit
  18. 01 Nov, 2013 5 commits
  19. 23 Oct, 2013 2 commits
  20. 05 Sep, 2013 1 commit
  21. 28 Jun, 2013 1 commit
  22. 16 Oct, 2012 2 commits
  23. 04 Jan, 2012 1 commit
    • Simon McVittie's avatar
      Revert all changes since a36d4918 · 5df8c3db
      Simon McVittie authored
      Someone seems to have merged part of master into 1.4. Again. Let's go
      back to the "last known good" point (the branch-point of some 1.4
      branches I had locally), then we can cherry-pick the changes that
      should have gone in.
      5df8c3db
  24. 28 Sep, 2011 1 commit
  25. 19 Sep, 2011 1 commit
  26. 13 Jun, 2011 2 commits