CONTRIBUTING: Remove all trailing whitespace

Signed-off-by: Simon McVittie <smcv@collabora.com>

1 files changed, 16 insertions, 16 deletions

diff --git a/CONTRIBUTING b/CONTRIBUTING
index a0d1db98..be0c919e 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -19,25 +19,25 @@ restricted to the "D-BUS security group".
 Most of D-Bus is security sensitive.  Guidelines related to that:
 
  - avoid memcpy(), sprintf(), strlen(), snprintf, strlcat(),
-   strstr(), strtok(), or any of this stuff. Use DBusString. 
-   If DBusString doesn't have the feature you need, add it 
-   to DBusString. 
+   strstr(), strtok(), or any of this stuff. Use DBusString.
+   If DBusString doesn't have the feature you need, add it
+   to DBusString.
 
    There are some exceptions, for example
-   if your strings are just used to index a hash table 
+   if your strings are just used to index a hash table
    and you don't do any parsing/modification of them, perhaps
-   DBusString is wasteful and wouldn't help much. But definitely 
+   DBusString is wasteful and wouldn't help much. But definitely
    if you're doing any parsing, reallocation, etc. use DBusString.
 
- - do not include system headers outside of dbus-memory.c, 
-   dbus-sysdeps.c, and other places where they are already 
-   included. This gives us one place to audit all external 
+ - do not include system headers outside of dbus-memory.c,
+   dbus-sysdeps.c, and other places where they are already
+   included. This gives us one place to audit all external
    dependencies on features in libc, etc.
 
- - do not use libc features that are "complicated" 
+ - do not use libc features that are "complicated"
    and may contain security holes. For example, you probably shouldn't
    try to use regcomp() to compile an untrusted regular expression.
-   Regular expressions are just too complicated, and there are many 
+   Regular expressions are just too complicated, and there are many
    different libc's out there.
 
  - we need to design the message bus daemon (and any similar features)
@@ -154,7 +154,7 @@ To make a release of D-Bus, do the following:
 
  - check out a fresh copy from Git
 
- - verify that the libtool versioning/library soname is 
+ - verify that the libtool versioning/library soname is
    changed if it needs to be, or not changed if not
 
  - update the file NEWS based on the git history
@@ -209,9 +209,9 @@ To make a release of D-Bus, do the following:
    previous release. Note that bullet points for each of the changelog
    items must be indented three more spaces to conform to the
    formatting of the other releases there.
-  
+
  - post to dbus@lists.freedesktop.org announcing the release.
- 
+
 
 Making a ".0" stable release
 ===
@@ -305,7 +305,7 @@ rules are:
    reviews and approves
 
  - for fixes that do affect API or protocol, two people
-   in the reviewer group have to review and approve the commit, and 
+   in the reviewer group have to review and approve the commit, and
    posting to the list is definitely mandatory
 
  - if there's a live unresolved controversy about a change,
@@ -329,9 +329,9 @@ rules are:
     - make check must pass
     - the test suite must be extended to cover the new code
       as much as reasonably feasible (see Tests above)
-    - the patch has to follow the portability, security, and 
+    - the patch has to follow the portability, security, and
       style guidelines
-    - the patch should as much as reasonable do one thing, 
+    - the patch should as much as reasonable do one thing,
       not many unrelated changes
    No reviewer should approve a patch without these attributes, and
    failure on these points is grounds for reverting the patch.