]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
Two CODING_STYLE additions
authorLennart Poettering <lennart@poettering.net>
Mon, 6 Jun 2016 15:24:21 +0000 (17:24 +0200)
committerLennart Poettering <lennart@poettering.net>
Mon, 6 Jun 2016 17:02:33 +0000 (19:02 +0200)
CODING_STYLE

index b689355c9a6611fdadfe09ab88f15ff3e61930a5..e762d42edb0249f1c2f2467f88fcc7c2079a685b 100644 (file)
   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.