s4:rpc_server: add dcesrv_call_session_info()

[samba.git] / README.Coding

diff --git a/README.Coding b/README.Coding
index fc807ef0f7b98f0331be9116d163a7fe4f9bde46..ac9bcd43065fea7246ecddafaeac389319087628 100644 (file)
--- a/README.Coding
+++ b/README.Coding
@@ -16,14 +16,14 @@ style should never outweigh coding itself and so the guidelines
 described here are hopefully easy enough to follow as they are very
 common and supported by tools and editors.
 
-The basic style for C code, also mentioned in prog_guide4.txt, is the Linux kernel
-coding style (See Documentation/CodingStyle in the kernel source tree). This
-closely matches what most Samba developers use already anyways, with a few
-exceptions as mentioned below.
+The basic style for C code is the Linux kernel coding style (See
+Documentation/CodingStyle in the kernel source tree). This closely matches
+what most Samba developers use already anyways, with a few exceptions as
+mentioned below.
 
 The coding style for Python code is documented in PEP8,
-http://www.python.org/pep/pep8. New Python code should be compatible with
-Python 2.6, 2.7, and Python 3.4 onwards. This means using Python 3 syntax
+https://www.python.org/dev/peps/pep-0008/. New Python code should be compatible
+with Python 2.6, 2.7, and Python 3.4 onwards. This means using Python 3 syntax
 with the appropriate 'from __future__' imports.
 
 But to save you the trouble of reading the Linux kernel style guide, here
@@ -100,6 +100,7 @@ AllowShortIfStatementsOnASingleLine: false
 IndentCaseLabels: false
 BinPackParameters: false
 BinPackArguments: false
+SortIncludes: false
 
 
 =========================
@@ -431,6 +432,22 @@ an iterator style:
                   ... do something with opt ...
        }
 
+Another exception: DBG messages for example printing a SID or a GUID:
+Here we don't expect any surprise from the printing functions, and the
+main reason of this guideline is to make debugging easier. That reason
+rarely exists for this particular use case, and we gain some
+efficiency because the DBG_ macros don't evaluate their arguments if
+the debuglevel is not high enough.
+
+       if (!NT_STATUS_IS_OK(status)) {
+               struct dom_sid_buf sid_buf;
+               struct GUID_txt_buf guid_buf;
+               DBG_WARNING(
+                   "objectSID [%s] for GUID [%s] invalid\n",
+                   dom_sid_str_buf(objectsid, &sid_buf),
+                   GUID_buf_string(&cache->entries[idx], &guid_buf));
+       }
+
 But in general, please try to avoid this pattern.