From 6d09d6b1550c976217a386d44628769d09fc31ac Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 16 Oct 2018 15:01:04 +0100 Subject: CONTRIBUTING: Remove all trailing whitespace Signed-off-by: Simon McVittie --- CONTRIBUTING | 32 ++++++++++++++++---------------- 1 file 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. -- cgit v1.2.1