X-Git-Url: http://git.samba.org/samba.git/?p=gd%2Fgnutls;a=blobdiff_plain;f=CONTRIBUTING.md;h=96fb7ff0cc7ac3810c28ddb3dd24cd71d8e5c5ff;hp=201efd133bba371bc5afd9ed1a24858c96dfa694;hb=HEAD;hpb=71afdf09b820180f3125eeefaeb787155e7333fc

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 201efd133..96fb7ff0c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -99,6 +99,9 @@ following.
  * ```gnutls_credentials_``` for the credentials structures
  * ```gnutls_global_``` for the global structures handling
 
+All exported API functions must be listed in libgnutls.map
+in order to be exported.
+
 Internal functions, i.e, functions that are not exported in the API but
 are used internally by multiple files, should be prefixed with an underscore.
 For example `_gnutls_handshake_begin()`.
@@ -108,9 +111,31 @@ not use the `_gnutls` prefix for simplicity, e.g., `get_version()`.
 
 Internal structures should not be exported. Especially pointers to
 internal data. Doing so harms future reorganization/rewrite of subsystems.
+They can however be used by unit tests in tests/ directory; in that
+case they should be part of the GNUTLS_PRIVATE_3_4 tag in libgnutls.map.
 
-All exported functions must be listed in libgnutls.map.in,
-in order to be exported.
+
+# Header guards
+
+  Each private C header file SHOULD have a header guard consisting of the
+project name and the file path relative to the project directory, all uppercase.
+
+Example: `lib/srp.h` uses the header guard `GNUTLS_LIB_SRP_H`.
+
+The header guard is used as first and last effective code in a header file,
+like e.g. in lib/srp.h:
+
+```
+#ifndef GNUTLS_LIB_SRP_H
+#define GNUTLS_LIB_SRP_H
+
+...
+
+#endif /* GNUTLS_LIB_SRP_H */
+```
+
+The public header files follow a similar convention but use the relative
+install directory as template, e.g. `GNUTLS_GNUTLS_H` for `gnutls/gnutls.h`.
 
 
 # Introducing new functions / API
@@ -154,7 +179,7 @@ should be introduced to enable the new behavior.
 When it is necessary, or desireable to enable the new features by default
 (e.g., TLS1.3 introduction), the "next" releases should be used (and
 introduced if necessary), to allow the modification to be tested for an
-extended amount of time.
+extended amount of time (see the [Release policy](RELEASES.md)).
 
 
 # API documentation