Preconditions to check for input probs and out of memory

 * We don't try to guarantee completely robust and problem
   free behavior in cases where the caller or process isn't
   behaving. We consider these to be outside of our control.

1 files changed, 31 insertions, 0 deletions

diff --git a/HACKING b/HACKING
new file mode 100644
index 0000000..63454f8
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,31 @@
+HACKING p11-kit
+
+ * Website: http://p11-glue.freedesktop.org/p11-kit.html
+
+ * Mailing list: p11-glue@lists.freedesktop.org
+
+ * Bugs: https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue
+
+PRECONDITIONS and UNEXPECTED SYSTEM ISSUES
+
+We don't try to guarantee completely robust and problem free behavior in cases
+where the caller or process isn't behaving. We consider these to be outside of
+our control:
+
+ * Broken input from callers. We use preconditions to check input
+   and immediately return.
+
+ * Out of memory. It is pretty much impossible to handle out of memory
+   errors correctly. Handling them alongside other errors is naive and
+   broken.
+
+   We do check the results from all memory allocations.
+
+   As a nod to the behavior of callers of this library, we don't abort on
+   memory allocation failures. We use preconditions with somewhat sane results.
+
+   We don't try to guarantee library state (such as locks or memory leaks)
+   when memory allocation fails.
+
+   Exception: when reading files or allocating potentially unbounded amounts
+   of memory, we should respond robustly to memory allocation failures.