summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2016-06-06 17:24:21 +0200
committerLennart Poettering <lennart@poettering.net>2016-06-06 19:02:33 +0200
commitd5af8eeab83d2c706af5b089539603dc2a434cc2 (patch)
tree9459bc8c745a9714c3cc0db62dc97e6f1762fbd0
parentb2bb19bbda8f5ab3ab497165bc52a0ef952348c4 (diff)
Two CODING_STYLE additions
-rw-r--r--CODING_STYLE17
1 files changed, 17 insertions, 0 deletions
diff --git a/CODING_STYLE b/CODING_STYLE
index b689355c9a..e762d42edb 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -382,3 +382,20 @@
tools, and we should continue to do so, as it makes it easy to
identify command line parameter variables, and makes it clear why it
is OK that they are global variables.
+
+- When exposing public C APIs, be careful what function parameters you make
+ "const". For example, a parameter taking a context object should probably not
+ be "const", even if you are writing an other-wise read-only accessor function
+ for it. The reason is that making it "const" fixates the contract that your
+ call won't alter the object ever, as part of the API. However, that's often
+ quite a promise, given that this even prohibits object-internal caching or
+ lazy initialization of object variables. Moreover it's usually not too useful
+ for client applications. Hence: please be careful and avoid "const" on object
+ parameters, unless you are very sure "const" is appropriate.
+
+- Make sure to enforce limits on every user controllable resource. If the user
+ can allocate resources in your code, your code must enforce some form of
+ limits after which it will refuse operation. It's fine if it is hardcoded (at
+ least initially), but it needs to be there. This is particularly important
+ for objects that unprivileged users may allocate, but also matters for
+ everything else any user may allocated.