Commit 6d09d6b1 authored by Simon McVittie's avatar Simon McVittie

CONTRIBUTING: Remove all trailing whitespace

Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
parent 64d7fa27
......@@ -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.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment